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ABSTRACT 


This  thesis  is  intended  to  demonstrate  the  technological 
feasibility  of  interfacing  numerous  automated  information 
systems  throughout  the  joint  deployment  community.  Through 
the  use  of  the  EDI  concept,  deployment  information  can  be 
transferred  between  commands  which  must  interact  in  order  to 
efficiently  and  effectively  plan,  execute,  and  coordinate 
deployment  efforts.  The  Electronic  Data  Interchange  is  a 
transaction  set  oriented  interchange  which  provides  the 
means  for  efficient  data  commuEication.  Implementation  of 
the  EDI  concept  will  tie  together  systems  throughout  the 
community  in  support  of  the  Jcint  Operation  Planning  and 
Execution  System  (JOPES)  . 
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I.  INTIODCCTION 

The  joint  deployment  commurity  is  dependent  upon  elec- 
tronic exchange  of  data  for  successful  operations.  Current 
systems  do  not  provide  the  necessary  commands  the  ability  to 
communicate  quickly  and  efficiently,  causing  information 
exchange  delays  and  erroneous  or  out-of-date  data  to  be 
transmitted.  Both  planning  and  execution  phases  of  deploy- 
ment operations  are  adversely  affected. 

The  Electronic  Data  Interchange  (EDI)  concept  has  been 
proposed  as  a  system  for  realizing  a  distributed  database 
approach  to  information  management,  the  approach  required  by 
the  Joint  Operation  Planning  and  Execution  System  (JOPES)  . 
The  EDI  concept  provides  a  means  for  electronic  interface 
among  commands  which  do  not  have  the  same  hardware,  soft- 
ware, or  database  management  systems.  While  there  are  many 
factors  to  be  considered  when  implementing  a  community-wide 
system,  and  not  all  concerns  or  issues  can  be  addressed  by 
any  one  system,  perhaps  one  of  the  most  basic  issues  is  the 
feasibility  of  implementing  an  exchange  system  such  as  the 
EDI  system. 

This  thesis  demonstrates  the  feasibility  of  implementing 
the  EDI  concept  throughout  the  joint  deployment  community. 
It  also  describes  the  connection  between  service  unique 
systems  and  the  system  supporting  the  joint  deployment 
syst  em. 

Chapter  II  provides  background  by  defining  the  Joint 
Deployment  System.  Its  current  planning  and  execution 
systems  are  outlined.  The  EDI  concept  is  then  examined,  and 
its  applicability  tc  the  present  system  is  described. 
Chapter  III  examines  the  EDI  concept  in  depth.  The 
mechanics   of   the   system  are   explained,    and   a   generic 


description  of  how  such  an  interface  is  accomplished  is 
given.  Chapter  IV  contains  a  description  of  the  scenario 
and  data  elements  used  to  demonstrate  the  proposed  inter- 
change system,  and  the  results  of  the  demonstration. 
Chapter  V  is  a  discussion  of  current  service  unique  systems 
which  exist  at  different  levels  through  the  joint  deployment 
community.  These  service  unique  systems  are  examined  with 
respect  to  their  interface,  both  current  and  potential,  with 
the  joint  deployment  system.  limitations  of  the  EDI  concept 
are  also  explored.  Chapter  VI  discusses  factors  which  must 
be  considered  when  implementing  this  system.  Implementation 
benefits  which  can  be  realized  through  the  use  of  the  £DI 
concept  are  then  summarized. 


II.    BACKGROUND 

The      Joint         Deployment      system  (JDS)         "consists        of 

personnel,  procedures,  directives,  communication  systems, 
and  electronic  data  processing  systems  to  directly  support 
time-sensitive  planning  and  execution  and  to  complement 
peacetime  deliberate  planning."  [Ref.  1]  The  community 
which  is  directly  concerned  with  the  JDS  ranges  from  organi- 
zations at  the  NCA  level  down  to  the  actual  deployable 
fighting  units.  The  amount  of  information  exchange  neces- 
sary to  provide  all  ccncerned  with  appropriate,  timely,  and 
accurate  information    is   staggering. 

A.       PLANNING 

There  are  two  distinctly  separate  types  of  planning 
within  the  JDS.  The  Crisis  Action  System  (CAS)  is  concerned 
with  planning  under  time-sensitive  or  crisis  situations. 
Deliberate  planning  is  planning  during  peacetime,  non-crisis 
operations.  Planning  for  joint  military  operations  and 
force  deployment  is  conducted  using  the  Joint  Operations 
Planning  System  (JOPS).  JOPS  consists  of  policies,  proce- 
dures, and  systems  used  to  support  force  deployment  plan- 
ning. The  ADP  portion  of  JOES  operates  on  the  Worldwide 
Military  Command  and  Control  System  (WWMCCS)  computer 
system.   [  Ref .  2  ]. 

1 •   Deliberate  Planning 

There  are  five  phases  to  deliberate  planning: 
initiation,  concept  development,  plan  development,  plan 
review,  and  supporting  plans.  These  phases  are  depicted  in 
Figure   2.1  [Ref.  3:    p.   5].     The  first   two  phases   are 
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concerned  with  defining  the  threat  and  establishing  an 
appropriate  concept  of  operations.  The  third  phase,  plan 
development,  has  as  its  objective  a  "transportation 
feasible,  implementable  plan."  During  Phase  IV,  plan 
review,  the  plan  is  revised,  taking  into  account  adequacy, 
feasibility,  suitability,  and  the  dynamics  of  change.  An 
approved  plan  is  ultimately  prcducred.  Phase  V  produces  a 
family  of  supporting  plans,  taking  into  consideration 
service  doctrine  and  support  agreements. 

The  primary  document  associated  with  deliberate 
planning  which  outlines  deployment  requirements  is  the  time- 
phased  force  deployment  data  (TPFDD) .  This  is  created 
during  the  Plan  Development  phase,  and  at  this  stage 
contains  the  information,  on  a  notional  basis,  needed  to 
describe  a  deployment. 

The  Transportation  Operating  Agencies  (TOAs)  are 
responsible  for  preparing  movement  schedules  which  support 
requirements  established  by  the  TPFDD.  In  order  to  accom- 
plish this,  the  TPFED  goes  through  an  extensive  refinement 
process,  with  actual  forces  identified  to  replace  the 
notional  forces.  Additionally,  specific  transportation 
requirements  and  unique  deploy nent  situations  are  identi- 
fied. The  execution  feasibility  of  identified  scheduled 
movements  is  tested  by  the  appropriate  TOAs,  using  service 
unigue  systems  and  software.  The  TPFDD  and  the  associated 
OPLAN  are  eventually  reviewed  and  approved  by  the  JCS,  and 
the  TPFDD  is  then  entered  into  the  deployment  data  base  at 
the  Joint  Deployment  Agency  (JDA) .  When  completed,  the 
TPFDD  contains  time-phased  force  data,  non-unit-related 
cargo  and  personnel  data,  and  transportation  data  for  the 
operation  plan,  including  supporting  units  with  associated 
priorities,  routing  of  forces  to  be  deployed,  associated 
mobility  data,  and  cargo  and  personnel  movements  to  be 
conducted   concurrently   with   the    deployment   of   forces. 


1  1 


PHASE  I 
Initiation 


Basis:     National  Security  Objectives 

Criteria:  The  Threat 

Planning  Tasks  and  Forces 

Objective:  To  Set  the  Stage 


PHASE  II 
Concept  Definition 


Basis:     Mission  Assignment  (Forecast  Assignment 
Criteria:   Force  and  Resource  Allocation 

All  Significant  Factors 

Concept  Adequacy 
Objective:  Derive  the  Concept 

of  Operations 


PHASE  III 
Plan  Development 


Basis:     The  Commander's  Concept 
Criteria:   Force  and  Resource  Allocation 
Service  Planning  Factors 
Strategic  Movement  Data 
Objective:  A  Transportation  Feasible 
Implementable  Plan 


PHASE  IV 
Plan  Review 


Basis:     The  Plan 

Criteria:   Adequacy  and  Feasibility 
The  Dynamics  of  Change 

Objective:  An  Approved  Plan 


PHASE  V 
Supporting  Plans 


Basis:     The  Approved  Plan 

Criteria:   Service  Doctrine 

Support  Agreements 

Objective:  A  Family  of  Plans 


Figure  2. 1    Phases  of  Deliberate  Planning 
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[Ref.  4]  This  refined  TPFDD  is  accessible  to  the  deployment 
community  and  can  be  updated,  tc  some  extent,  by  the  TOAs  as 
required.  Continual  interaction  between  JDA  and  the  TOAs, 
as  well  as  interaction  between  two  or  more  TOAs,  is  neces- 
sary for  the  successful  refinement  of  the  TPFDD.  Various 
stages  of  refinement  require  interaction  at  conferences,  via 
telephone,  and  via  computer  systems  which  support  the  JDS. 
Once  the  TPFDD  is  established,  interaction  is  primarily 
through  the  computer  systems.  Efficient,  accurate  interac- 
tion is  necessary  for  the  deployment  data  base  to  accurately 
reflect  troop/supply  movement,  as  well  as  changing  require- 
ments cr  force  assignments. 

2  •   Crisis  Action  Planning 

The  Crisis  Action  System  provides  a  framework  within 
which  time-sensitive  planning  can  be  accomplished.  The 
procedures  are  intended  to  provide  each  level  of  command  the 
information  necessary  to  develop  timely  recommendations  to 
aid  the  NCA  in  making  decisions  involving  U.S.  military 
forces  in  the  execution  of  military  courses  of  action. 
[Ref.  5:  p.  II-1 ] 

There  are  six  phases  tc  the  crisis  action  system, 
which  are  outlined  in  Figure  2.2.  Both  the  TOAs  and  JDA  are 
involved  immediately  in  any  crisis  action  planning.  During 
Phase  I,  the  joint  deployment  community  monitors  the  situ- 
ation, as  JDA  ensures  that  the  joint  deployment  system  is 
operational.  During  Phase  II,  as  existing  OPLA Ns  are  being 
assessed  at  the  NCA  level,  the  crisis  action  teams  at  the 
TOAs  and  JDA  are  activated  and  plans  are  assessed  at  that 
level  as  well.  Coordination  between  the  CINCs  involved  and 
the  joint  deployment  community  also  takes  place.  During 
Phase  III  coordination  between  the  CINCs,  the  TOAs  and  JDA 
increases,  as  the  TOAs  prepare  preliminary  deployment  esti- 
mates based  on   commanders1  estimates.   JDA  is  also  involved 
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with  coordinating  the  estimates  from  the  TOAs  and  providing 
both  JCS  and  CINCs  with  the  consolidated  estimates. 
Throughout  the  execution  phases  the  TOAs  and  JDA  continue  to 
update  and  coordinate  the  force  deployment  data  base  as 
actual  movements  are  initiated  and  completed,  and  as 
requirements  change  during  the  conflict.  [Eef.  5:  pp.  II-2 
-  II-9] 

During  Phase  V  the  TOAs  begin  actual  scheduling, 
concentrating  on  the  first  six  days  for  air  and  the  first  30 
days  for  sea  transportation.  JDA  verifies  the  accuracy  of 
the  data  base  before  the  TOAs  tegin  their  scheduling,  and 
resolves  transportation  problems  between  TOAs,  supporting 
and  supported  commanders.  During  Phase  VI  the  TOAs  and  JDA 
continue  to  manage  and  coordinate  transportation  require- 
ments, respond  to  changes,  repcrt  deployment  deviations  and 
diversions  in  JDS,  and  provide  deployment  status  to  those 
concerned,  from  the  TOA  level  tc  the  JCS. 

3-   Joint   Operation    Plan  cinq   and    Execution   System 
(JO  PES) 

The  Joint  Operation  Planning  and  Execution  System 
(JOPES)  concept  was  approved  in  July  1983,  and  was  envi- 
sioned as: 


the  foundation  for  cur  conventional  command  and  control 
system.  JOPES  will  support  mcnitoring  of  readiness,  and 
monitoring,  planning.  and  execution  of  mobilization, 
deployment,  employment,  and  sustainment  activities  both 
in  peacetime  and  under  crisis  and  wartime  conditions. 
[Ref.  6:  p.  1] 


JOPES  came  into  being  primarily  because  of  the  extensive 
redundancy  of  JOPS  and  JDS.  Although  they  are  two  separate 
systems,  the  functions  and  products  of  each  are  so  entert- 
wined  that  neither  system  functions  efficiently  without 
considerable  interaction  with  the   other.    Although  not  yet 
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fully  operational,  JOPES  will  consist  "...of  the  policy, 
procedures,  software,  hardware,  personnel,  training,  and 
connectivity  necessary  to  facilitate  planning,  directing, 
coordinating,  monitoring  and  controlling  military  opera- 
tions." [Eef.  7]  The  effective  implementation  of  such  a 
system  will  require  a  distributed  data  base  structure  within 
the  ftWMCCS  community. 

B.   SERVICE  UNIQUE  AUTOMATED  SYSTEMS 

There  are  numerous  automated  systems  throughout  the 
services  which  are  related,  in  varying  degrees,  to  the 
deployment  community  as  a  whole,  and  to  the  joint  deployment 
system.  Figure  2.3  lists  some  of  these  systems,  and  indi- 
cates their  interrelationships.  It  should  be  obvious  that 
an  interface  between  key  systems  involving  data  required  to 
effectively  plan  and  execute  fcrce  deployment  would  greatly 
enhance  the  effectiveness  and  efficiency  of  such  operations. 
Although  not  as  clearly  indicated  in  Figure  2.3,  interfaces 
between  differing  commands  using  the  same  systems  frequently 
either  are  not  fully  automated,  or  have  inherent  serious 
time  delays  which  create  data  mismatches  and  inaccuracies. 

The  automated  systems  throughout  the  joint  deployment 
arena  are  constantly  changing  ard  growing  to  meet  the  needs 
of  the  community.  Many  of  the  problems  identified  two  and 
three  years  ago  have  been  partially  or  completely  solved 
since  then.  There  are  still,  however,  significant  problems 
concerning  the  implementation  cf  required  interfaces.  As 
service-unique  systems  proliferate,  interface  requirements 
become  both  more  numerous,  and  easier  to  accomplish.  For 
example,  as  a  system  which  automates  unit  requirements  data 
comes  on-line,  it  creates  a  need  for  an  interface  which  can 
provide  that  data,  in  required  format,  for  use  by  transpor- 
tation agencies  within  the  deployment  community.   While  this 
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creates  a  need  for  an  interface,  it  also  simplifies  the 
problem  of  data  exchange,  as  automated  interfaces  are  faster 
and  easier  than  providing  that  same  data  manually  from  the 
original  data  location  to  the  TOAs  for  input  in  the  joint 
deployment  system. 

The  necessity  for  interfaces  between  appropriate  systems 
(and  appropriate  commands  withir  the  same  system)   is  widely 
recognized.   Implementation  on  a  significant  basis,  however, 
has  not  teen  accomplished. 

C.   EXISTING  INTEBFACE  METHODS 

There  are  a  variety  of  methods  currently  in  use  for 
accomplishing  data  transfers.  For  those  organizations  not 
in  the  WWMCCS  Intercomputer  Network.  (WIN)  ,  there  are  essen- 
tially two  means  available  for  transmitting  information 
between  physically  separate  locations.  As  antiquated  as  it 
may  seem,  one  primary  method  is  the  use  of  the  U.S.  Postal 
Service.  In  numerous  instances,  actual  output  listings  from 
the  different  systems  are  mailed  to  the  units,  the  units 
make  pen  and  ink  changes  as  the  status  of  forces  and  eguip- 
ment  changes,  then  the  listirgs  are  mailed  back  to  the 
computer  site  for  update  to  the  actual  file.  In  the 
interim,  continuous  telephone  communication  between  the 
parties  involved  helps  keep  the  files  from  becoming 
uselessly  out  of  date. 

In  other  cases,  the  existirg  AUTODIN  is  used  to  provide 
either  tape-to-tape  or  card-to-card  transfer  of  data.  In 
either  instance,  when  AUTODIN  is  used  there  is  a  consider- 
able human  interface  required  which  not  only  slows  the 
transfer  process  but  always  introduces  an  unnecessary  error 
factor. 

A  third,  significantly  more  efficient,  method  of  data 
transfer   in  use   today  is   the  WIN.     For  those   locations 
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having  access  to  WIN  the  human  interface  is  minimized.  WIN 
not  only  allows  for  automatic  tape-to-tape  transfers  tut 
also  provides  a  means  of  computer-to-computer  disk  transfer. 
Disk-to-disk  transfers  are  ccrsiderabiy  faster  and  more 
efficient  than  tape-to-tape.  This  is  primarily  due  to  the 
sequential   nature      of   a    tape    transfer.  When    automatically 

sending  data  over  communications  lines,  there  is  always  the 
danger  of  a  break  in  communications  service,  a  'timeout 
period'.  Under  the  present  WIN  system,  once  a  tape  transfer 
is  interrupted,  for  whatever  reason,  it  is  physically  impos- 
sible to  restart  the  tape  at  some  point  in  the  middle.  This 
means  that  the  sending  tape  is  rewound  and  the  entire  tape 
retransmitted.  Tape-to-tape  transfers  are  an  all  too  common 
occurrence  in  interfacing  the  systems  within  the  SWMCCS 
today.  Although  WIN  disk-to-disk  transfers  are  considerably 
more  efficient,  the  present  need  for  standardization  of  both 
the  software  and  hardware  required  to  accomplish  the 
exchange   introduces   another    more   complicated   issue. 

D.   STANDARDIZATION 

One  of  the  methods  suggested  to  accomplish  the  necessary 
interchange  of  information  is  community- wide  standardiza- 
tion. This  method  has  traditionally  been  used  in  the 
computer  industry,  for  several  reasons.  Initially,  this  was 
the  only  alternative  available;  technology  was  not  readily 
available  which  would  permit  any  meaningful  communication 
between  different  vendors'  equipment.  It  was  only  with  the 
advent  of  numerous  companies  and  systems  and  the  resulting 
profusion  of  previously  incompatible  equipment  that  efforts 
were  made  to  develop  methods  of  computer-to-computer 
communications. 

The  first  generation  of  interfaces  required  a  consider- 
able   amount   of    standardization.  Programs    which    translated 
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from  one  system  to  a  totally  different  system  were  designed 
primarily  as  one-time  conversion  opportunities.  Whether  for 
technological  or  commercial  reasons,  standardization  was 
considered  necessary. 

The  next  stage  in  the  evolution  of  computer  communica- 
tions involves  interfaces  that  eliminate  the  need  for  stan- 
dardization. These  are,  however,  relatively  new,  and  are 
not  as  well  known  or  understood  as  standardization.  Perhaps 
because  of  this,  the  standardization  solution  to  the  data 
exchange  problem  throughout  the  joint  deployment  community, 
as  well  as  elsewhere,  has  been  proposed  by  many  concerned 
with  the  issue.  Certainly  standardization  of  data  elements 
and  format  (and  possible  hardware  as  well)  would  provide  the 
opportunity  for  automated  data  exchange.  Unfortunately, 
there  are  also  significant  drawbacks  to  standardization. 
The  most  obvious  may  be  that  the  joint  deployment  community 
already  abounds  with  guite  a  variety  of  "non-standard"  hard- 
ware and  software.  The  conversion  in  equipment  costs  alone 
becomes  impractical.  Equally  as  important,  however,  is  one 
of  the  underlying  reasons  for  the  existence  of  the  differing 
software  and  hardware:   differing  applications  needs. 

The  commands  within  the  joint  deployment  community  are 
responsible  for  different  missions,  and  their  daily  require- 
ments emphasize  different  aspects  of  the  deployment  picture. 
The  same  transaction  (e.g.,  shipment  of  tanks  from  Ft.  Ord, 
California  to  Misawa,  Japan)  is  of  differing  importance  to 
different  levels  in  the  joint  deployment  community  (the 
initiating  unit,  the  Transportation  Operating  Agency 
involved,  the  unit  assigned  to  carry  the  tanks,  and  the 
Joint  Deployment  Agency) .  The  importance  of  individual  data 
elements  involved  in  this  transaction  vary  from  command  to 
command.  Additionally,  each  command  involved  has  ether 
reporting  requirements  within  its  own  service  which  require 
data  in  certain  format.    To   require  identical  data  element 
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formats  and  transmission  structures  at  each  node  of  this 
transportation  operation  would  introduce  inefficiencies  on 
the  local  level.  That  is,  data  elements  either  not  neces- 
sary or  formatted  differently  at  a  local  level  may,  for  the 
"good"  of  the  community,  becone  leading  data  items  which 
must  he  formatted  and/or  transmitted  differently.  A  further 
complication  can  be  illustrated  when  items  as  simple  as  a 
shipping  date  are  standardized.  Different  commands  may 
organize  filing  or  retrieval  systems  by  day  or  month; 
reguiring  every  command  in  the  joint  deployment  system  to 
place  the  day  first  introduces  unnecessary  confusion  at 
those  locations  where  other  daily  tasks  reguire  the  month 
first. 

E.   ELECTRONIC  DATA  INTERCHANGE  CONCEPT 

Electronic  Data  Interchange  (EDI)  is  a  computer-to- 
computer  data  exchange  system  designed  to  be  used  by  both 
industry  and  government.  The  EDI  system  objective  is  to 
develop  and  maintain  standards  for  the  electronic  inter- 
change of  data  between  any  tyje  or  size  of  companies  or 
government  agencies.  These  standards  were  developed  in  a 
joint  industry/government  program  sponsored  by  the  United 
States  Department  of  Transportation.  In  order  to  accommo- 
date the  reguirements  of  the  najority  of  potential  users, 
the  Transportation  Data  Coordinating  Committee  (TDCC)  was 
assigned  the  task  of  establishirg  and  maintaining  the  stan- 
dards. TDCC  in  1985,  recognizing  that  potential  applica- 
tions of  EDI  systems  were  not  limited  to  the  transportation 
industry,  changed  their  name  to  EDI  Association.  The  first 
set  of  EDI  standards,  published  in  1975,  coordinated  the 
reguirements  of  ocean,  air,  motor,  and  rail  carriers.  In 
addition,  these  same  standards  were  designed  to  meet  the 
needs  of   the  users   of  the   carrier  services.     Subsequent 
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enhancements  have  been  made  to  the  EDI  standards  in  response 
to  reguests  from  the  user  community. 

The  EDI  software  uses  a  'table-driven'  technique  to 
generalize  processing  regardless  of  the  application  being 
processed.  Specific  directions  are  taken  by  the  software 
depending  on  the  data  being  processed  and  the  particular 
tables  associated  with  the  applications.  The  EDI  software 
resides  in  each  participants'  computer  system  and  is  an 
interface  between  EDI  format  structures  and  the  partici- 
pant's internal  system.  The  EDI  software  assumes  that  an 
EDI  participant  already  has  an  automated  system  in  use  for 
processing  internal  applications.  Some  of  these  internal 
applications  require  data  from  external  (outside  the  partic- 
ipant's system)  sources  or  provide  data  to  external  points. 
The  format  for  these  interagency  data  transfers  is  given  in 
the  EDI  standards.  EDI  is  not  an  independent  system  but  is 
meant  to  interface  existing  in-house  systems.  TDCC  EDI 
software  eases  the  transition  from  a  completely  closed 
internal  system  to  an  internal  system  with  a  controlled 
external  interface.   [Ref.  8] 

EDI,  Incorporated  is  a  company  independent  of  the  TDCC 
with  a  staff  which  works  as  systems  consultants  to  TDCC  and 
has  comprehensive  and  detailed  knowledge  of  the  EDI  stan- 
dards and  the  TDCC  software.  EDI,  INC.  has  performed  a 
significant  role  in  the  industry-wide  acceptance  of  the  EDI 
standards  as  a  viable  means  cf  data  interchange.  This 
company,  under  contract,  designed  the  software  to  link  users 
in  the  grocery  industry,  the  transportation  industry,  and  is 
currently  under  contract  with  the  Military  Sealift  Command 
and  the  Military  Traffic  Jlanageaent  Command. 

The  emphasis  of  the  EDI  concept  is  on  the  exchange  of 
information  between  computers  through  the  use  of  standard 
transaction  sets.  This  provides  one  of  the  major  benefits 
of  such  a  system:    the   users  preserve  their  autonomy  while 
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efficiently  interfacing  with  ether  users.  There  is  no 
requirement  for  different  users  to  use  the  same  hardware, 
software,  or  even  data  base  management  systems.  This  also 
provides  the  additional  benefit  of  being  able  to  add  or 
delete  individual  data  elements  without  requiring  software 
logic  changes.   [Ref.  7:  p.  42] 

The  EDI  interface  creates  a  data  exchange  structure  in 
the  format  depicted  in  Figure  2.4.  With  this  structure 
modifications  to  one  user's  applications  do  not  affect  other 
users.  The  interface  software  is  between  the  individual 
user  and  the  standard  data  set.  Once  all  nodes  of  the 
structure  can  interface  with  the  standard,  data  exchange  can 
be  accomplished  between  any  twe  nodes,  with  no  additional 
interface  requirements  necessary  for  communication  between 
the  two  nodes.  The  interface  acts  as  a  transparent  partner; 
from  the  user's  viewpoint  the  communication  is  directly  with 
the  second  user.  The  overall  number  of  interfaces  required 
for  communication  between  all  ncdes  is  therefore  reduced  (to 
four  in  the  example  in  Figure  2.4  from  six  if  the  standard 
transaction  set  was  not  available).   [fief.  7:  p.  34] 


Figure  2.4    Interfacing  Through  a  Standard  Data  Set 
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F.   SUMMARY 

It  should  be  apparent  that  the  flow  of  information 
between  relevant  commands  during  both  deliberate  planning 
and  crisis  actions  must  be  timely  and  accurate.  The  data 
base  required  to  support  such  planning  and  execution  must  be 
accessible  to  all  involved,  and  must  be  kept  current.  Thus, 
effective  interchange  of  information  necessitates  a  network 
which  is,  as  much  as  possible,  automated,  easy  to  use  at 
each  node,  and  reliable.  The  EDI  concept  is  one  proposal 
available  to  accomplish  this  interchange.  The  resulting 
network  should  encompass  service  unique  automated  systems  as 
well  as  the  specific  computer  system  supporting  JDS. 
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III.  ELECTRONIC  DJTA  INTERCHANGE 

A.   INTRODUCTION 

Data  interchange  is  concerned  with  the  transmission  and 
interpretation  of  information  among  participants-  The 
proposed  EDI  interface  is  a  computer-to-computer  data 
exchange  system  which  utilizes  a  disk-to-disk  transfer.  Its 
purpose  is  to  simplify  the  integration  of  external  communi- 
cations with  internal  applications  programs.  The  previous 
chapter  introduced  the  EDI  concept;  this  chapter  will 
describe  in  some  detail  the  mechanics  of  the  i  interchange 
system.  Areas  of  importance  include  the  EDI  software  and 
the  data  and  format  structures.  Definitions  of  concepts 
which  are  integral  to  an  understanding  of  the  following 
discussion  are: 


IHt^£f§£^  Sy_stem:  Interface  system  refers  to  the 
computer  programs  to  be  used  to  construct  or  edit  infor- 
mation communicated  between  electronic  data  interchange 
systems  and  the  internal  applications  programs  of  a 
participant. 

Electronic  Data  Interchange :  Electronic  data  inter- 
change means  €Ee  Transmission  of  transaction  data,  in 
formats  selected  in  the  EDI  standards,  between  two  or 
more  companies  or  organizations  having  business  rela- 
tionships. 

Internal  Applications:  Internal  applications  refers  to 
Eh"e  use  of  electronic  data  processing  equipment  to 
support  internal  operational  information  functions.  The 
electronic  data  interchange  system  interfaces  with  tut 
does  not  include  internal  applications.   [ Ref .  9] 


It  must  be  emphasized  that  the  EDI  concept  represents  an 
interface  between  existing  internal  automated  systems  and 
external  automated  systems.  It  supplements  existing  systems 
in  that  data  transfer  and   communication  are  enhanced.    The 
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EDI  system  does  not  provide  internal  data  manipulation  capa- 
bilities, nor  will  it  (of  itself)  produce  such  things  as 
reports,    data   summaries,    or    OPLMs. 

B.       EDI    SOFTWARE 

The  EDI  software  resides  in  each  command's  computer 
system,  and  provides  an  interface  between  that  system  and 
EDI  format  structures.  This  software  extracts  data  from  an 
internal  system's  automated  data  base  for  transmission  to 
other   commands.  When   receiving    data    from      other    commands, 

the  same  software  puts  information  into  the  data  base. 
Objectives    for    the    EDI   software   are: 

To    automatically    generate    and   interpret   data 

To    process  transaction    sets. 

To    ensure   common    interpretation      of    transmission    by   both 
the   sender  and   receiver. 

To    code   information  when   practicable. 

To    use   fixed    format  standards. 

To    eliminate    data    net    likely    to   be    used. 

To   allow      for    flexibility    so      that    the   standards      may   be 
enhanced   as   needs    change   or    evolve.      [ Eef .    9:    pp.    2-3] 


1  •      Sof_t. war e   Operation 

The  key  to  EDI  software  operation  is  its  method  of 
transmission.  The  required  data  is  first  transformed  into 
EDI  transaction  sets,  then  transmitted  in  standard, 
compressed  format.  Upon  receiving  a  transmission,  the  soft- 
ware 'explodes*  the  compressed  data  into  fixed  format 
records  defined  by  the  receiving  user  which  are  compatible 
with  the  user's  internal  software  and  database.  The  order 
of  elements  in  a  given  user's  record  structure  does  not  have 
to    be   the   same    as    that      used   by   the    EDI    software.         Software 
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procedures  and  interfaces  rearrange  the  data  as  necessary. 
The  EDI  software  uses  a  column  of  information  in  one  of  the 
EDI  tables  (Table  4,  explained  below)  in  order  to  'under- 
stand1 the  locations  cf  given  data  elements.  The  interfaces 
between  EDI  software  and  the  user's  overall  system  are 
diagrammed  in  Figure  3. 1  Those  modules  within  the  dark  box 
make  up  the  EDI  software.   [Ref.  9:  p.  28]. 

2 .   Tables 

To  facilitate  change  and  modification,  the  EDI  soft- 
ware is  'table-driven1.  The  tables  define  formats  and  edit 
parameters  for  use  by  the  program.  The  five  tables  used  by 
the    EDI    software  are   as   follows: 


Table  1 
Table  2 
Table  3 
Table  4 
Table  5 


Set  Pointers 

Segments  for  Each  Transaction  Set 

Segment  Pointers 

Data  Elements  for  Each  Segment 

Data  Elements  [Ref.  9:  pp.  43-44] 


Their  functions  are  described  in  Figure  3.2  [Ref.  9:  p.  35]. 
The  same  five  tables  used  for  generation  of  data  tc  be 
transmitted  are  used  for  interpretation  of  received  data. 
The  software  programs  maintain  pointers  to  the  tables. 
These  pointers  are  moved  as  necessary  during  processing  in 
order  to  edit  or  generate  data  formats. 

3-   Software  Programs 

There  are  t «o  EDI  operational  software  programs: 
Set  Generator  for  transmission  and  Set  Interpreter  and 
Parser  for  reception.  These  programs,  in  addition  to  main- 
taining table  pointers,  use  the  information  at  the  pointer 
locations  in  conjunction  with  information  from  the  internal 
data  base  to  assure  program   operation  and  interpretation  of 
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Figure  3.  1         Data   Interchange   Program   Modules 

data.  The   Set      Generator,       using      the    above      information, 

composes   transaction    sets   in      proper    transmission    structure. 
The    Parser    extracts    data    elements   from   the    continuous   stream 
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Table  1  is  used  to  locate  items  in  Table 
2. 

Table  2  gives  the  order  of  segments  in  a 
transaction  set  for  each  application. 

Table  3  is  used  to  locate  items  in  Table 
4. 

Table  4  gives  the  order  of  data  elements 

in  each  segment. 

Table  4  example  (simplified) : 


Segment  I.D. 


Data  Element 


Location 


EX  (Example) 

EX 

EX 

EX 


D 
A 
E 
C 


11 
1 

13 
9 


Table  5  specifies  data  element  attributes 
Table  5  example  (simplified) : 

Data  Element     Maximum  Length 


A 

4 

B 

4 

C 

2 

D 

2 

E 

12 

F 

8 

Figure  3.2   The  Five  EDI  Tables 
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of  characters  received,  and  forwards  the  data  to  the  Set 
Interpreter.  The  Set  Interpreter  edits  incoming  transaction 
sets.  The  resulting  data  is  passed  to  the  internal  applica- 
tions routine. 

C.   EDI  DATA  AND  FOBHAT  STRUCTURE 

1 .  Data  Dictionary 

All  EDI  system  transaction  segments  and  transaction 
sets  are  constructed  from  basic  building  blocks  which  are 
contained  in  the  Data  Dictionary-  Within  this  'dictionary', 
all  data  elements  are  defined  in  a  standardized  format. 
This  does  not  indicate  a  need  for  standardization  among 
commands,  however.  The  internal  systems  used  by  commands 
will  interface  with  this  'centralized1  standard  through  the 
interchange.   The  data  dictionary  includes  the  following: 

-  Data  Element  Number 

-  Data  Element  Name 

-  Data  Element  Description 

-  Field  Length 

-  Characteristics 

-  Reference  Designators  [Eef.  10:  p.  153] 

Appendix  A  is  an  example  of  part  of  a  data  element 
dictionary.  The  first  five  items  above  are  self- 
explanatory;  the  reference  designators  refer  to  the  trans- 
action sets  in  which  the  particular  element  is  used. 

2.  Units  of  Information 

There  are  three  basic  units  of  information  used  in 
the  EDI  data  interchange.  These  units  may  be  of  variable 
length  and  relate  to  each  other  as  shown  in  Figure  3.3 
[Eef.    10:    p.    5], 
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They  are  defined  as  fellows: 


Data  Element:  The  smallest  information  unit  in  the  EDI 
information  structure  is  the  data  element.  A  data 
element  may  be  a  single  character  code,  a  series  of 
characters  constituting  a  literal  description  or  a 
numeric  quantity. 

Data  Segment:  A  data  segment  is  composed  of  a  function 
iHentixier  and  one  or  more  functionally  related  data 
elements  positioned  serially  in  a  standard  manner. 

Transaction  Set:  A  transaction  set  is  that  group  of 
slandarH  data  segments,  in  a  predefined  sequence,  needed 
to  provide  all  of  the  data  reguired  to  define  a  complete 
transaction  such  as  purchase  order,  invoice,  bill  of 
lading,  or  freight  bill.   [Eef.  9:  pp.  4-6] 


Additionally,  transaction  sets  are  grouped  into  functional 
groups,  which  are  combined  for  transmissions.  Appropriate 
segments  are  inserted  throughout  these  levels  in  order  to 
ensure  communication  coherency.  These  additional  units  are 
called  format  units  and  are  located  at  the  beginning  and 
ending  of  segments,  as  shown  in  Figure  3.4  [Eef.  9:  p.  7] 
Except  where  noted,  these  segments  are  required.  Although 
not  pictured,  there  are  alsc  format  units  at  the  data 
segment  and  data  element  levels. 

Each  data  segment  begins  with  a  unique  '  data  segment 
identifier'  and  ends  with  a  'data  segment  terminator'.  The 
first  is  composed  of  alpha/nuneric  characters,  while  the 
latter  is  either  an  EBCDIC  cede  or  ASCII  code  character 
[Eef.  9:  p.  6].  At  the  data  element  level  the  format  unit 
is  known  as  a  'data  element  delimiter',  and  is  represented 
by  an  "*".  It  follows  each  data  element  in  a  segment  except 
the  last  (it  also  fellows  the  segment  identifier).  The 
asterisk  is  also  transmitted  whenever  there  is  no  data  being 
transmitted  for  a  defined  element  other  than  the  last 
element  in  a  segment.  This  preserves  the  data  element 
count.  The  information  required  to  completely  describe  a 
data  segment  is  depicted  in  Figure  3.5. 


32 


Canmuni  cat  ions  Protocol 


Transmission  Control  Heaaer  Segment  (BG) 
Functional  Control  Header  Segment  (55) 


Transaction  Set  Control  Heaaer  Segment  (ST  ) 
(Beginning  Segment) 


Detail  Data  Segments 
(e.g.  Purcnase  Graer) 


Transaction  Set  Control  Trailer  Segment  (SE) 
(Enaing  Segment) 

Transaction  Set  Control  Heaaer  Segment  (ST  ) 
(Beginning  Segment) 


Detail  Data  Segments 
(e.g.  Purcnase  Jroer) 


■Transaction  Set  Control  Trailer  Segment  (SE) 
(Enaing  Segment) 


Functional  Control  Trailer  Segment  (GE) 
Functional  Control  Heaaer  Segment  (G5) 


Transaction  Set  Control  Heaaer  Segment  (ST  ) 
(Beginning  Segment) 


Cetail  Data  Segments 
(e.g.  Receiving  Advice] 


Transaction  Set  Control  Trailer  Segment  (SE) 
(Enaing  Segment) 


Functional  Control  Trailer  Segment  (GE) 
Transmission  Control  Trailer  Segment  (EG) 
:mmuni cat  ions  Protocol  
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Figure  3.U   Transmission  Structure 
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8   3    5 

1  -  Set  Identifier 

2  —  Reference  designator:  Segment  identifier  followed 

by  sequence  number  within  segment 

3  -  (A)  Alpha;  (N)  Numeric;  (AN)  Alpha/Numeric; 

(Dn)  Implied  Decimal  (with  n  places  to  right 
of  implied  decimal  point),  (R)  Decimal  (with 
decimal  point  explicitly  required),  (NZ)  Numeric— zero 
4—  Data  element  name 

5  -  Minimum/maximum  number  of  characters 

6  -  Data  element  reference  number 

7—  New  line  character  or  carriage  return,  line  feed 

8—  (M)  Mandatory;  (C)  Conditional;  (O)  Optional 

9—  Special  relational  conditions 
10  -  Delimiter 

Figure  3.5    Transaction  Sejaient  Format 

3.   Communications  Interface 

The  EDI  software  utilizes  512  character  blocks. 
Existing  communica tions  may  utilize  blocks  of  other  lengths. 
There  is  no  need  to  change  either  the  EDI  software  or  the 
length   required   for   the   comnunica tions   protocol.     The 
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communications    software      used    should    adapt    to      both    lengths, 
as    indicated   in    Figure   3.6    [Ref.    9;    pp.    42,    44]. 


COMMUNICATIONS 


EDI 

SOFTWARE 

512 

CHARACTER 
BLOCK 

COMMUNICATIONS 
SOFTHARE 

DATA 

BLOCX 

(LENGTH  PER 
COMMUNICATIONS 
PROTOCOL) 


Figure  3-6   Communications  Interface 


D.   SOHHARY 

The  EDI  concept  provides  an  interchange  between  auto- 
mated systems  internal  and  external  to  a  command  or  organi- 
zation. The  software  resides  within  a  command's  system,  and 
uses  a  table-driven  technigue  to  allow  for  generalized 
processing,  regardless  of  the  application  being  processed. 
It  is  generic  in  that  no  specific  hardware  or  software  is 
reguired,  and  in  fact  many  different  vendors  may  be  used 
with    no    degradation    in   system    capabilities. 

Within  the  EDI  software,  data  elements,  data  segments, 
and  transaction  sets  are  used  to  convert  differing  formats 
to  standardized  format  for  transmission,  and  again  at  the 
receiving  end  to  reconstitute  the  transmission  into  formats 
acceptable  to  the  receiver.  As  should  be  obvious  after  the 
generic  description  of  the  software  mechanics  throughout 
this  chapter,  this  concept  is  applicable  at  many  different 
levels  throughout  the  joint  deployment  community,  as  well  as 
elsewhere   in   DOD. 
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IV.  DEMONSTRATION 

A.   INTRODUCTION 

As  discussed  in  Chapter  II,  the  joint  operation  planning 
procedure  is  an  ongoing,  day-to-day  process.  Operation 
Plans  (OPLANs)  are  continuously  being  developed  and  revised 
to  ensure  there  is  an  OPLAN  designed  to  meet  any  anticipated 
contingency.  An  integral  part  cf  every  OPLAN  is  identifica- 
tion of  those  military  units  required  to  implement  the  given 
plan.  Once  specific  units  are  identified,  the  Joint 
Deployment  System  comes  into  play  in  determining  the  trans- 
portation assets  needed  to  deploy  those  units  to  the  oper- 
ating location.  This  process  is  also  an  ongoing,  continuous 
procedure.  As  OPLANs  are  revised,  the  transportation  needs 
may  change;  as  units  acguire  new  equipment  or  modify  the 
old,  their  transportation  needs,  again,  may  change. 

In  order  to  ensure  that  the  transportation  assets  are 
available  to  fulfill  the  requirements  of  any  OPLAN,  the 
Joint  Deployment  Agency,  as  part  of  the  JDS,  maintains  a 
central  data  base  containing  all  of  the  specific  information 
regarding  the  deployment  needs  cf  every  military  unit.  This 
is  necessarily  a  very  large,  complex  data  base  and  it  is 
easy  to  visualize  the  tremendous  task  involved  in  keeping 
the  data  current  and  accurate.  The  specific  procedures 
employed  to  modify  and  update  this  data  base  vary  depending 
on  the  unit,  the  service,  and  TCA  involved  in  the  particular 
scenario.  In  any  case,  the  applicability  of  an  automated 
interface  between  JDS  and  the  organization  involved  in  the 
data  update  process  is  obvious. 

lor  the  purpose  of  demonstrating  the  feasibility  of 
using  the  EDI   system  of  data  interchange   in  the  deployment 
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arena,  we  developed  a  scenario  involving  one  unit,  one  TOA , 
one  command  headquarters,  and  the  JDA.  It  is  important  to 
remember  that  what  we  are  demonstrating  is  only  one  very 
small  portion  of  the  overall  coamunications  process  and  data 
transfer  which  transpires  routinely  in  maintaining  the  JDS 
data  lase. 

In  this  scenario  development,  we  will  first  identify  the 
agencies  selected  to  exemplify  the  'typical'  data  fiow,  then 
discuss  how  these  agencies  are  currently  accomplishing  the 
task  of  maintaining  the  data  on  a  daily  basis,  and  then  pose 
a  crisis  situation  which  requires  that  the  actual  system  be 
forced  into  action.  Finally,  we  will  show  an  example  of  the 
same  automated  systems  interfaced  using  EDI  as  compared  with 
the  current  procedures. 

B.   SCENARIO 

We  selected  the  Army's  Military  Traffic  Management 
Command  (MTMC)  as  the  TOA  involved  in  the  transport  of  the 
deploying  unit.  In  particular,  we  selected  the  7th  Infantry 
Division  out  of  Ft.  Ord,  CA  as  the  unit  to  be  deployed.  The 
geographical  location  of  Ft.  Ord  requires  transport  of  the 
unit  through  flTMC  Western  Area  (HTHCSA)  in  Oakland,  CA . 
Because  we  are  dealing  with  an  Army  unit,  the  Forces  Command 
{FORSCOM)  in  Atlanta,  GA  also  becomes  a  player.  And,  of 
course,  the  goal  of  our  scenario  is  to  show  how  each  of 
these  organizations  interfaces  with  the  Joint  Deployment 
Agency   and    the    JDS    in  Tampa,    FL. 

Each  of  the  above  organizations  uses  a  number  of 
different  automated  systems  for  managing  their  assets.  In 
this  demonstration  we  will  deal  only  with  FORSCOM 's  COMPASS 
which  produces  the  Automated  Unit  Equipment  List  (AUEL) ,  and 
MTMC's  SPUR.  The  current  procedures  require  the  following 
steps. 
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•  The  unit,  here  7th  Infantry  Division,  receives  a  copy 
of  its  AUSL  from  the  COMPASS.  The  Installation 
Transportation  Officer  (ITC)  ,  or  his  staff,  reviews  the 
AUEL  and  periodically  subaits  any  updated  information 
about  7th  ID'S  equipment  tc  FORSCOM. 

•  FORSCOM  maintains  the  accurate  status  of  each  unit's 
equipment.  Section  D  of  this  chapter  contains  examples 
of  the  types  of  information  maintained  in  the  COMPASS 
data  base. 

•  FCESCOM  creates  a  tape  for  transfer  to  JDS,  with  the 
entire  description  of  each  unit's  equipment. 

•  JDA  updates  the  Unit  Movecent  Data  (UMD)  file  in  JDS 
from  the  tape  transferred  from  FORSCOM.  Section  D 
contains  examples  of  the  tjpes  of  data  in  the  UMD. 

•  FORSCOM  creates  a  second  tape  for  transfer  to  MTMC 
Headquarters  in  Washington,  D.C.  This  tape  contains 
the  same  basic  information  about  unit  equipment  as  that 
sent  to  JDA. 

•  MTMC  Headquarters  manually  extracts  classified  data 
from  the  COMPASS  tape  and  forwards  an  edited,  unclassi- 
fied version  of  the  tape  tc  MTMCHA. 

•  HTMCWA  receives  the  tape  from  Headquarters  and  inputs 
the  data  into  the  System  for  Predetermining  Unit 
Requirements  (SPDRs) .  SPURs  is  the  on-line  system  that 
is  used  by  the  TOAs  to  schedule  and  manifest  7th  ID  on 
a  particular  vessel. 

•  At  the  time  7th  ID  is  manifested,  MTMCWA  must  interface 
with  JDS  to  reflect  the  iranifest  information  in  that 
data  base.  It  is  the  JDS  which  will  be  used  by  all 
other  participants  in  the  successful  deployment  of  7th 
ID.  For  instance,  the  Military  Airlift  Command  (MAC) 
may  also  provide  air  assets  for  equipment  and  troop 
deployment. 
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The  major  assumption  in  this  process  is  that  all  three 
organizations  and  their  associated  data  bases;  i-iTMCVTA  in  the 
SPURS,  FCRSCOM  in  the  COMPASS,  and  JDA  in  the  JDS,  will  all 
have  the  exact  information  regarding  7th  ID'S  equipment  and 
transportation  requirements.  This  assumption  personifies 
the  major  flaw  in  the  existing  system.  Because  of  the  human 
intervention  required  to  extract  classified  portions  of  the 
data  and  the  amount  of  time  involved  to  accomplish  tape  to 
tape  transfers,  whether  using  AUIODIN  or  WIN,  there  are 
often  significant  differences  ir  these  three  data  bases.  It 
is  essential  that  MTMCWA,  where  the  unit  is  actually  mani- 
fested, has  the  most  accurate  information  at  all  times.  It 
is  just  as  important  that  JDA,  as  the  coordinator  of  the 
overall  deployment,  not  limited  to  7th  ID,  also  have  the 
most  accurate  information. 

In  an  attempt  to  stay  current,  the  users  of  the  SPURs 
maintain  an  off-line,  but  direct,  communication  with  all  of 
the  units  under  its  responsibility.  This  direct  correspon- 
dence serves  the  purpose  of  data  currency  but  tends  to 
further  complicate  the  situatior.  Upon  receipt  of  unit  data 
through  the  COMPASS  to  SPURs  interface,  the  MTMCKA  transpor- 
tation specialist  must  ascertain  whether  this  data,  or  that 
which  he  received  direct  from  the  unit,  is  the  correct 
information. 

C.   INTERACTION  DURING  CRISIS  DEPLOYMENT 

In  the  previous  section  we  discussed  the  daily  interac- 
tions between  four  particular  nodes  in  the  overall  deploy- 
ment process.  The  procedures  outlined  in  Section  B  are 
routinely  accomplished  without  the  added  complications  of  an 
actual  crisis  situation.  Obviously,  when  a  crisis  does 
occur,  some  of  these  procedures  will  be  eliminated  while  the 
time  constraint  on   others  will  be  greatly   accelerated.    A 
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simple   example  of   how   an   actual  crisis   operation   might 
develop  is  described  below. 

•  First,  we'll  assume  a  crisis  situation  emerges  some- 
where in  the  Pacific  Theater.  This  implies  that 
CINCPAC  becomes  both  the  unified  and  the  supported 
commander.  For  the  purpose  of  this  discussion  we  hill 
also  assume  that  both  MAC  and  MTMC  are  involved  as  TOAs 
responsible  for  troop  and  equipment  deployment. 
However,  we  will  discuss  only  HTMC's  deployment  role. 
It  is  very  important  to  remember  the  significant  role 
MAC  would  also  be  playing  during  the  overall  data 
exchange  process. 

•  As  the  crisis  develops  there  is  constant  communication 
and  coordination  throughout  the  entire  military  commu- 
nity. CINCPAC  submits  a  Commander's  Assessment  to  the 
Joint  Chiefs  of  Staff.  This  report  outlines  what 
forces  he  has  readily  available,  the  major  constraints 
to  their  employment,  and  his  proposed  course  of  action. 
JCS  reviews  the  situation  with  the  services  and  TOAs. 
The  NCA  is  continually  kept  informed  by  the  JCS  and 
through  the  WWMCCS  communication  systems.  Throughout 
this  process  the  JDS  data  base  is  accessed  to  provide 
the  latest  information  regarding  major  unit  force 
strengths  and  their  transportation  requirements. 
[Eef.  3:  p.  10] 

•  Eventually,  as  the  situation  progresses,  JCS  issues  a 
Warning  Order  containing  guidance  from  the  NCA 
pertaining  to  the  crisis.  Based  on  the  Warning  Order, 
another  round  of  communications  between  CINCPAC,  the 
service  components,  the  supporting  commanders,  and  the 
TOAs  transpires.  The  result  of  all  this  effort,  with 
again  significant  references  to  the  JDS  data  base  for 
supporting  data,  is  the  selection  of  a  specific  Course 
of  Action  (COA) .   [Ref.  3:  p.  10] 
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•  The  JCS  recommend  this  COA  to  the  Secretary  of  Defense 
and  the  President.  If  the  President  decides  to  proceed 
with  the  COA  involving  military  forces,  the  JCS  issues 
an  Alert  Order  to  CINCPAC.  In  response  to  the  Alert 
Order,  the  supporting  commands  and  TOAs  prepare  an 
Operation  Order.   The  JDA  assists  this  process  by: 


"...updating  the  force  list  and  coordinating  the  deploy- 
ment of  schedules  by  the  transportation  operating  agen- 
cies. The  deployment  data  base  at  the  Joint  Deployment 
Agency  constitutes  the  authoritative,  up-to-date  source 
or  force  and  resupply  information.  The  data  base  can  be 
queried  by  the  enrire  deployiient  community  using  WIN." 
I Ref .  3:  p.  12 ] 


•  Finally,    if   the   President  decides   tD   execute   the 
planned  operation,   the  Secretary   of  Defense,   through 
the  JCS  issues  an  Execute   Order  instructing  CINCPAC  to 
execute  his  Operation  Order.     This  begins  the  process 
of  deployment  execution. 
The  execution   phase  of  a  deployment   operation  requires 
constant   contact    and   coordination   by   all    supporting 
commanders  and  TOAs,  in  our  case  FORSCOM  and  MTMC.   In  actu- 
ality,  the  7th  Infantry  Division  would  have  been  identified 
as   a   proposed   supporting   unit    during   the   process   of 
selecting  the  appropriate  course  of   action.    With  even  the 
possibility  of   using  7th  ID,    FORSCOM  would   have  notified 
that   commander,    requested  updated   AUEL   information   and 
forwarded  the  current  status  of  7th  ID  troops  and  equipment, 
along  with   their  transportation  requirements,   to   the  JDS. 
All  of  the  information  must  be  available  prior  to  the  actual 
COA  selection. 

Once  7th  ID  is  officially  notified  of  the  order  to 
deploy,  the  transportation  process  is  activated.  MTHCWA 
begins  arrangements  for  ship  movement  of  heavy  equipment  to 
the  nearest  port  to  the  scene  of  the  crisis.  In  this 
instance,   7th   ID  departs  from   Oakland,   CA,   the   Pert  of 
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Embarkation  (POE)  and  will  be  shipped  to  a  Port  of 
Debarkation  (POD)  somewhere  in  the  Pacific. 

The  actual  manifest  on  the  ship  is  accomplished  item  by 
item  as  the  equipment  and  supplies  are  loaded.  This  ensures 
an  accurate  account  of  the  exact  load  being  transported. 
This  exact  manifest  information  is  required  for  both  billing 
and  more  importantly,  for  proper  identification  at  the 
receiving  POD.  The  manifest  information  is  then  entered 
into  the  JDS  data  base  by  plans  personnel  on  site  at  MTMCWA 
in  Oakland.  It  is  obvious  that  these  individuals  must  have 
the  correct  data  pertaining  to  7th  ID*s  deployment  to  the 
POD. 

This  marks  the  beginning  of  many  problems  which  arise  as 
a  result  of  the  data  transfer  procedures  discussed  in 
Section  B.  The  exact  manifest  information  is  known,  at  this 
point  in  time,  only  by  those  individuals  responsible  for  the 
actual  manifest  activity.  However,  when  this  data  is  loaded 
into  the  JDS  data  base,  the  JDS  system  often  rejects  the 
entry-  In  fact,  whenever  manifest  data  differs  in  any  way 
from  the  planned  equipment  lead  reflected  in  the  Unit 
Movement  Data  (UMD)  file  maintained  in  JDS,  an  entry  error 
is  created.  This  data  rejection  causes  a  significant  time 
lag  in  the  effectiveness  of  the  overall  deployment  process. 

D.   DEMONSTRATION 

The  problems  arising  under  the  current  data  transfer 
procedures  can  be  significantly  reduced  through  the  applica- 
tion of  the  EDI  concept.  The  use  of  EDI  for  one  of  the  data 
transfers  described  in  section  B  above  is  demonstrated 
below. 

Figure  4.1  is  a  ccpy  of  the  data  format  for  the  COMPASS 
Automated  Unit  Equipment  File  (AUEL) .  Figure  4.2  is  a  copy 
of  the  data  format  for  the  Unit  Movement  Data  (UMD)   file  in 
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JDS.  Appendix  B  is  the  EDI  transaction  set  which  would  be 
used  to  transfer  data  from  one  system  to  the  other.  The 
data  elements  which  are  required  for  transfer  between  the 
two  systems  are  indicated  by  the  alphabetic  characters  to 
the  left  of  the  data  element  name  in  Figures  4.1  and  4.2 
The  same  letters  (i.e.,  a,  b,  c,  etc.)  are  used  to  indicate 
the  same  item  of  data  within  each  file.  It  should 
be  noted  that  the  same  data  items  are  often  in  different 
locations  and  use  differing  field  lengths  in  each  system. 

Tracing  a  single  data  element  through  the  transmission 
process  should  illustrate  the  operation  of  the  EDI  method. 
Figure  4.3  contains  one  item  of  information,  as  shown  in  the 
AUEL  record  format  and  the  Automated  Unit  Eguipment  listing. 
The  equivalent  data  element  in  FDI  format  is  also  shown,  as 
is  that  item  positioned  in  the  FDI  transmission  format.  The 
JDS  UMD  record  format  for  the  same  item  is  also  shown. 
These  have  been  extracted  from  the  complete  document  exam- 
ples, as  shown  in  Figure  4.1,  Appendix  C,  Appendix  E,  Figure 
4.4,  and  Figure  4.2,  respectively. 

The  item  labeled  (a)  in  the  record  formats  for  AUEL  and 
JDS  is  equivalent  to  one  EDI  element,  element  #111.  For 
this  example,  it  is  the  first  element  in  Data  Segment  D1, 
which  is  part  of  Transaction  Set  #365.  (See  Figure  3.3  for 
the  relationship  between  elements,  segments,  and  sets.  See 
also  Appendix  B.) 

The  arrows  in  Figure  4. 3  indicate  the  conversion  flow 
for  this  item.  Through  the  use  of  the  EDI  tables  (see 
Figure  3.2)  residing  in  the  EEI  conversion  software,  the 
information  in  positions  1-6  of  field  1  in  the  AUEL  detail 
record  is  put  in  EDI  format.  This  element,  Unit 
Identification  Code  (WHGHAA  for  this  example) ,  which  is 
mandatory,  alpha/numeric,  and  six  characters  (see  Figure  3.5 
for  location  of  this  information)  is  placed  in  the 
appropriate  location  in  the  data  segment.   Upon  receipt,  the 
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RFCORD   SPECIFICATION 


ID:      AUTL-Detail  TITLE:      AITEL  Cargo   Detail   Record 

DESCP-IFTIOM;      Contains    laforaation  to   identify  and  describe   cargo   shlpoenc   units 
applicable    to   unit   moves. 

CLASSIFICATION;      UNCLASSIFIED  LENGTH:    105 


(a) 

1-6 

1 

(b) 

7 

2 

8-13 

3 

14 

4 

15-23 

5 

H-22 

6 

(J) 

23-43 

7 

44-55 

3 

56— S3 

9 

61-42 

13 

(e) 

63-66 

11 

(h) 

75-81 

14 

(0 

82-33 

15 

89 

16 

(c) 

93-92 

'  17 

(d) 

93 

13 

94-135 

23 

POSITION      FIF.LD     FIELD   TITLES RT?        LCTH  PXMAFXS 

Unit   Identification  Code    (UIC) 
Type   Unit   Movement   Data    (TTPEDATA) 
Stipaent  Cnit    Nuaber    (SHIPCNR) 
Load   Nuaber    (LCAXNR.) 


Line    Itea  Nuaber   (LDO 

LEI   Index   Nuaber    (LLXLKIXNZ) 

Itea   Description   (nomenclature) 
(ITEKDESC) 

Model    Nuaber    (MCDELNR) 

Water   Cocaocity   Code    (WCCMMCD) 

Type    Packing    (TTFEPACK) 

Itea   Length   Rounded    (ITD!LCTH?jrD) 


(  f )         67-73  12  Itea  Width  Rounded    (ITEMVDTKFjn) 

(q)  71-74  13  Itea  Height   Rounded    (ITrMHOTRFJfD) 

Cross  Weight  Pounds  (CRVTL3S) 

Itea  Cubic    Feet   Rounded    (ITEMCUS-TRND 

Mode   to   POE   (MCDETOP0E) 

Cargo   CJtegorty  Code      (CCCCAICtE) 

Heavy    Lift    Code      (HVTLFT) 

Filler 


A/N 

6 

Control    Field 

A/N 

•       1 

Control   Field 

A/N 

6 

Control   Field 

A/N 

1 

Control   Field 
Value    is    "JT 
or  nuaeric 

A/N 

6 

N 

2 

A/N 

21 

A/N 

12 

A/N 

5 

• 

A 

2 

N 

4 

Rounded    to 
nearest    inch 

N 

4 

Rounded    to 
nearest    Lr.ch 

N 

4 

Rounded    to 
nearest    t  r.rh 

N 

7 

)      N 

7 

A 

1 

A/N 

3 

A/N 

A/N 

1 
12 

Figure   4.1         Automated    Unit   Equipment    File    Format 


t 

TRANS-UMD 

-DATA 

(COMPASS  FILE  DATA) 

Ql   TRANS-UMD-DATA. 

02 

TRANS-UMD-HDR . 

05 

FILLER 

PIC 

X(5)  . 

05 

TRANS-UMD-AREA 

PIC 

99  UALUE  99. 

05 

TRANS-UMD- FUNCTION 

PIC 

X  . 

88   TRANS-UMD-ADD 

UALUE  "A". 

88   TRANS-UMD-CHG 

UALUE  "C". 

88   TRANS-UM.D-DEL 

UALUE  "D" . 

05 

TRANS-UMD-OCCURS 

PIC 

99  UALUE  14. 

05 

TRANS-UMD-LENGTH 

PIC 

9(4)  UALUE  102. 

05 

FILLER 

PIC 

X  . 

05 

TRANS-UMD-SUC-CODE 

PIC 

X. 

05 

TRANS-UMD- PROUORG 

PIC 

X  . 

05 

TRANS-UMD- ROUTE- LINK 

PIC 

X(6)  . 

05 

TRANS-UMD-ROUTE-IND 

PIC 

X 

05 

TRANS-UMD- ROUTE -MAP 

PIC 

X(6) 

02 

TRANS-UMD. 

(a) 

05 

TRANS-UMD-UIC 

PIC 

X(6)  . 

05 

TRANS-UMD-MOUEMENT-CRP . 

(c) 

10   TRANS-UMD-CARGO- 

CAT 

PIC 

X(3)  . 

(d) 

10   TRANS-UMD-HEAUY- 

LIFT 

PIC 

X  . 

05 

TRANS-UMD-REC-TYPE 

PIC 

X. 

05 

FILLER 

PIC 

X(8)  . 

(b) 

05 

TRANS-UMD-TYPE-DATA 

PIC 

X. 

05 

TRANS-UMD- R EC -CLASS 

PIC 

X. 

.,._  _.  ... 

05 

TRANS-UMD-R EC- INDICATOR 

PIC 

X  . 

Figure  4.2    Joint  Deployment  System  OMD  File  Format 
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05   TRANS-UMD-REC-CREATED 
05   TRANS-UMD-REC-LAST-CHG 
02   TRANS-LEUEL-1 . 

05   TRANS-UMD-NBR-CARGO-CATS 
05   TRANS-UMD-TOT-STONS-BU 
05   TRANS-UMD-TOT-MTONS-BU 
05   TRANS-UMD-TOT-STONS-OUR 
05   TRANS-UMD-TOT-MTONS-OUR 
05   TRANS-UMD-TOT-STONS-OUT 
05   TRANS-UMD-TOT-MTONS-OUT 
05   TRANS-UMD-TOT-STONS-NAT 
05   TRANS-UMD-TOT-MTONS-NAT 
05   TRANS-UMD-BULK-POL 
05   FILLER 
02   TRANS-UMD-LEUEL-2  REDEFINES  TR ANS-UMD-LEUEL 
05   TRANS-UMD-CARG0-CAT-SUM-SQF7 
05   TRANS-UMD-CARGO-CAT-SUM-STONS 
05   TRANS-UMD-CARGO-CAT-SUM-MTONS 
05   FILLER 
02   TRANS-UMD-LEUEL-3  REDEFINES  T R ANS-UMD- LEUEL 
05   FILLER 

05   TRANS-UMD-QUANTITY 
(j)    05   TRANS-UMD-CARGO-DESCRIPTION 

(e)  05   TRANS-UMD-CARGO-LENGTH 

(f)  05   TRANS-UMD-CARCO-WIDTH 

(g)  05   TRANS-UMD-CARCO-HEICHT 
05   TRANS-UMD-CARGO-SQFT 

(h)   05   TRANS-UMD-CARCO-STONS 
(i)   05   TRANS-UMD-CARGO-MTONS 
05   FILLER 


-1  . 


-1 


PIC  9(6) . 
PIC  9(6) . 

PIC  9(3) . 
PIC  9(6)U9. 
PIC  9(7)  . 
PIC  9(6)U9. 
PIC  9(7)  . 
PIC  9(6)U9 . 
PIC  9(7) . 
PIC  9(6)U9. 
PIC  9(7) . 
PIC  9(7)  . 
PIC  X(2)  . 

PIC  9(6)  . 
PIC  9(b)U9  . 
PIC  9(6)  . 
PIC  X(50) . 

PIC  X(  14)  . 

PIC  9(3)  . 

PIC  X(  14)  . 

PIC  9(4)  . 

PIC  9(3)  . 

PIC  9(3) . 

PIC  9(4) . 

PIC  9(5)U9 

PIC  9(6) . 

PIC  X(21)  . 


Figure    4.2    Joint    Deployment    System    OHD   File    Format     (cont'd) 
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AUEL  Record  Format 


■ 

1 

POSITION 

FIELD 

1 

FIELD   TITLES 

RE? 
A/N 

LGTH 
6 

Unit   Identification  Code    (DIC) 

C(a) 

„    ) 

(b) 

1           7 

2 

Type  DQiC  Movement  Data   (TYPEDATA) 

a/n 

1 

1      8-13 

3 

Shipment   Uait   Number   (SHIPUNB.) 

A/N 

6 

1 

Automate!  Unit  Eguipment  Lijting 


HE«0TIA9TEP$      J  n [  T  c  J     STATES     4? MY     I 


c  o  ••!  p  u  r  e  a  1 1  £  o    <  o  *  £  -i  e  n  r    planning   am 


C01P«5S     P  E  3  0  *  T    -     J NIT     E 


FYPE  DATA    ?  JNIT  ,\IA*S    020?  *P  CO 


S  HI P^ENT     UN  I T 


3  1  IE  NS  IONS 
(INCHES  ) 


0  E  S  C  il  I  P  T  I  0  N 


*O0El 


l  g r h    goTH    HiTrt   si 


00  2  G 1  5  gTiOOr1    01     rP5[l_E»     CAHG0     1/4     ro-'l     v4 1  6 


1 1 »        ft  ? 


EDI   Transmission    Format 


D4»Q^R *B 

DlfWHGHAMR*0209  MP  C0~FT  nEADE*MD*US 

D2*W9^400**0l-h416*875Z9-VE-U*3 


4 


/  JDS    UMD 


Record    Format 


OS       TRANS-UMD-ROUTE.-MAP 
02       TRANS-qjjlO. 


PIC    X(6) 


r 


(a)  OS       TRANS-UMD-UIC 


PIC    X(6) 


D 


OS       TRANS-UMD-MOUEMENT-GRP 


r       ^    JCJ    D, 

ita    Set    Format 

i — r 

i          i 

1  D101      111 '  ' 
l                             I 

1 D102      1461      '  D103        931      ' 
1                      II                      II 

I          I 
I  D1  |  * 

I         | 

1                            1 

i    u,c    r 

1  .       ^       1  -  1      Name      ,  -  , 

UMD 
1                      II                            1 

1         1 

|  n        AN      06/06 1   j    |  H        AN      01/01)        |  0          AN    01/35 1        | 

1 'vrr-— —          __.»'' ' 

Figure  4.3    Conversion  Flow  of  a  Single  Data  Item 
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EDI  software  at  the  receiving  site  transforms  this  element 
(again,  through  the  use  of  the  tables)  into  JDS  format,  as 
determined  by  JDS  record  format  requirements.  It  is  then 
available  for  inclusion  in  JDS  reports  or  for  visual  recall 
as  part  cf  any  one  of  a  number  cf  information  screens  on  the 
system  terminals  at  JDA. 

This  same  conversion  flow  occurs  for  each  piece  of 
information  which  must  be  transmitted.  It  is  especially 
important  to  note  the  number  and  size  of  those  data  items 
found  in  the  AUEL  file  but  not  used  in  the  UMD  file.  Under 
the  current  system  this  information  is  automatically  trans- 
ferred to  JDA  and  stripped  fron  the  file  after  receipt  of 
the  entire  file.  Using  the  IDI  method,  only  those  data 
elements  actually  used  are  transferred.  This  can  be  seen  in 
Figure  4.4,  which  shows  the  data  after  it  has  been  converted 
into  EDI  standard  data  elements  and  data  segments  for  trans- 
mission. All  other  fields1  can  be  transferred  using  one  or 
more  of  the  optional  data  segnents,  but  only  when  deemed 
appropriate  by  the  sender. 

Appendix  C  contains  examples  of  the  types  of  data  main- 
tained in  COMPASS  and  transferred  to  JDS.  The  data  in  these 
listings  is  currently  transferred  in  the  record  format  shown 
in  Figure  4.1  Exaaination  of  these  listings  shows  the 
considerable  duplication  of  data  being  transmitted.  The 
same  essential  information,  in  a  considerably  more  compact 
form,  is  transmitted  using  EDI  Transaction  Set  365,  Unit 
Movement  Data  (Appendix  B)  .  This  transaction  set,  while 
demonstrating  the  basic  format  of  transaction  sets,  also 
lists  the  associated  data  segments  which  would  be  required 
for  this  specific  application.  Appendix  A  is  a  section  of  a 
Data  Element  Dictionary,  which  includes  a  partial  list  of 
the  data  elements  used  in  these  data  segments.  Comparison 
between  present  formats  and  the  EDI  transmission  set  (Figure 
4.4  shows  that  considerable  reduction  in  transmitted  infor- 
mation can  be  realized  using  EDI. 
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TRANSACTION  SET  -  "355  UNIT  MOVEMENT  OATA 

(EG  SEGMENT) 
(GS  SEGMENT) 


ST-365-TRANS0001 

8GF-FI-F1203 

N1-FW-1JSARMY  FORSCCM-S-COMPASS 

N2*US  ARMY   FORCES  COMMAND  HEADQUARTERS 

N1»TQ»JQINT  DEPLOYMENT  AGENCY  "5-JDS/UnO 

01-GHIJKL-O-0051   AD  BN  91   9TY  A  VULC'FT  ORD'CA-US 

02-X60823  — 02-M151A2-975Z9-V0-U-7 

03-TRUCK  UTILITY   1/4  T0N-132-54-S3-N-24SC-L-2S5-E 

04-OVR-g 

D2-'U9S400—  01-M41S~97SZ9-,JE«U-7 

03-TRAILER  CARGO   1/4  T0N»132"54»S3"N*24SG*L*2S5,,E 

D4-QVR-A 

02-X39940— 02-M5 1 6 1    WWN-975Z9-V0-U-2 

D3-TRUCK  CARGO   1-1/4  TON-23l-6S-72"N»7480n_-92a-£ 

D4-0VR-K 

02-J96845— Q2-ni67«97SZ9-vE-U-1 

03 -GUN  AA  TOWED  2CMM-153-78-66-N-3260-L-467-E 

D4-GUR-S 

D1-WGHAA-R-02C9  MP  CO -FT  MEAOE-rQ-US 

02-U9S400— Qi-n416-975Z9-vE-*J-3 

03-TRAILER  CARGO   1/4  TCN-lG9-52-44»N»530-L-17a-£ 

04-DVR-A 

D2-'tf95400(A)— 01— tlX-U-3 

03 -LOAD -n ISC  TOE  ORG  ECUIP— SQ0-L-2Q-E 

02-X40009— Q2-M25A2-973Z9-vO-tJ-l 

03-TRUCK  CARGO  2-1/2  T0N-265-95-88-N-1318Q-L-1292' 

04 -OUR -S 

D2-X4Q009(A)  — 02— MXnj-1 

D3-L0A0-MISC  TOE  ORG  EQUIP— 482Q*L-270*€ 

02-X40146—  02-M35A2  WUN-375Z9-VQ-U-1 

03-TRUCK  CARGO  2-1/2  T0N-279»9S-88-N»13S7Qt»1359' 

D4-QUR-S 

02-X401 46(A)—  02—  MX-U-1 

D3-LQA0-MISC  TOE  ORG  EQUIP— 4820-L-270-E 

02-y9S3 1 1  — 02-M 1 0SA2-97SZ9-VE-U-2 

03-TRAILER  CARGO   1-1/2  T-!66-e3-S2"N»2570-L-554-£ 

D4-0VR-9 

02-y953l1(A)—  02— MX-U-2 

03-L0AD-MISC  TOE  ORG  EGUIP— 293Q-L-200-E 


K 4 -COMMENTS 
SE-23-TRANS0001 


(GE  SEGMENT) 
(EG  SEGMENT) 


Figure  4.4        Transmission    of    Data    Set    #365   in    EDI    Format 
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E.       EDI    ADVANTAGES 

The  data  elements,  segments,  and  sets  utilized  in  the 
EDI  concept  are  designed  to  be  applicable  to  a  wide  variety 
of      applications.  Through      the   use      of      the      tatle-driven 

system,  command  unique  forms  can  be  translated  into  generic 
data  elements,  and  combined  into  transaction  sets  which  can 
be   transmitted       to    many      other    crganizations.  Because    the 

receiving  organizations*  EDI  software  will  translate  the 
transmitted  elements  into  locally  desired  formats,  the  same 
transmission  could  actually  result  in  reports  in  vastly 
different   formats      at   multiple    locations.  This    highlights 

one  of  the  major  benefits  of  the  EDI  procedures:  standard 
formats  are  not  required  for  effective  community-wide  data 
transfers. 

As  shown  above,  the  problems  arising  under  the  current 
data  transfer  procedures  are  primarily  the  result  of  ineffi- 
cient use  of  existing  communications  assets.  As  previously 
discussed  the  current  system  requires  transfer  of  the  entire 
COMPASS  file,  including  data  elements  not  required  for  use 
in  JDS.  This  file  is  then  interpreted  at  JDA,  the  necessary 
data  is  extracted  frcm  the  COMPASS  file  and  inserted  in  the 
proper  format  into  the  UMD  file  in  the  JDS  data  base.  The 
actual  file  transfer  is  acconplished  as  a  tape-to-tape 
transfer   using    the   File    Transfer   Service     (FTS)    of    the   FIN. 

The  basic  nature  of  a  tape-to-tape  transfer  automati- 
cally makes  this  a  relatively  slow,  inefficient  process.  In 
a  rather  volatile  network,  subject  to  frequent,  if  minor, 
interruptions  in  communications  service,  this  often  necessi- 
tates numerous  retransfers  of  previously  delivered  data  in 
an    effort      to    ensure    accuracy    of      the   total    file.  In    this 

demonstration,  we  propose  a  disk-to-disk  transfer  in  order 
to  eliminate  the  need  to  retransmit  the  entire  file  if  the 
transfer    is      interrupted   by      a    communications      break.         This 
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alone  will  significantly  reduce  the  time  lag  between  the 
locations  involved,  and  thus  increase  the  probability  that 
the  data  will  agree  at  both  sites. 

An  even  more  effective  difference  between  the  current 
transfer  method  and  the  EDI  method  demonstrated  here  is  in 
the  vastly  reduced  amount  of  data  required  to  be  sent.  The 
EDI  method,  as  shown  in  Figure  4.4,  requires  that  only  those 
data  elements  actually  used  at  the  receiving  site  be  trans- 
ferred. The  determination  of  required  elements  is  made 
through  the  table-driven  operations.  Data  elements  not 
required  are  listed  as  optional  in  the  data  segments.  In 
fact,  in  some  cases  the  data  segments  are  optional, 
depending  upon  to  which  site  (s)  the  transaction  set  is 
transferred.  By  eliminating  unnecessary  data  from  the 
transaction  set,  the  sender  can  ensure  the  most  efficient 
use  of  the  computer  systems  and  the  communications  network. 
In  this  example,  a  reduction  of  approximately  50%  in  trans- 
mitted data  would  be  realized. 

F.   SUMMARY 

within  the  joint  deployment  community,  extensive  data 
transfers  are  necessary  for  planning  and  execution  of 
deployment  efforts.  In  a  scenario  involving  MTMCWA,  7th 
Infantry  Division,  FOESCOM,  and  JDA,  data  transfers  such  as 
the  one  demonstrated  would  be  required.  The  current  trans- 
fers utilize  tape-to-tape  transfers  and  transmit  entire 
reports,  including  redundant  information,  and  information 
utilized  at  the  originating  end  but  not  the  receiving  end. 
Data  transfers  to  satisfy  the  same  scenario  requirements, 
but  utilizing  the  EDI  method,  provide  several  benefits. 
Conversion  to  multiple  formats  for  multiple  receivers  is  not 
necessary.  Disk-to-disk  transfers  reduce  the  necessity  for 
retransmission    in   case   of    interrupted   transmission. 
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Additionally,         the      reduced      amount        of      data      transmitted 
decreases   the   burden    en   communications  assets. 
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V.  INTERFACE  APPLICATIONS 

A.   INTRODUCTION 

The  previous  chapters  have  established  the  necessity  for 
an  efficient  electronic  data  interchange,  and  have  demon- 
strated the  technical  feasibility  of  the  EDI  concept  as  just 
such  an  exchange. 


Deployment  management  systens  (personnel,  hardware- 
communications  equipment,  software,  procedures)  must 
collectively  support  the  deployment  process  from  the 
National  Command  Authorities  *(NCA)  level  to  the  instal- 
lation level  using  fully  integrated  concepts  which 
maximize  our  deployment  capabilities  and  provide  neces- 
sary surge  capacity  to  meet  time-sensitive  crisis  and 
wartime  requirements.   [Ref.  11:  p.  14] 


Joint  planning  experiences  and  exercises  have  shown  the  need 
for  better  coordination  and  understanding  of  the  myriad 
mobilization  and  deployment  information  systems  which  either 
currently  exist  or  have  been  conceptually  determined. 
[Ref.  2]  A  brief  discussion  of  some  of  these  systems  should 
highlight  potential  applications  of  an  interchange  such  as 
the  EDI  concept. 

B.   INTEGRATED  NETWORKS 

1 .   TC  ACCIS 

One  siynificant  advancement  toward  the  implementa- 
tion of  an  automated  interface  is  the  development  of  the 
Transportation  Coordinator  Automated  Command  and  Control 
Information  System  (TC  ACCIS)  prototype.  TC  ACCIS  is  a 
response  to  lessons  learned  during  JDA  directed  exercises 
regarding  our  ability  to  deploy  forces  and  sustain  materiel 
and  personnel  under  crisis  conditions.   The  JDA  is  the  Joint 
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Project  Manager  of  this  development  effort  which  is  being 
conducted  within  the  WWMCCS  Eesearch  and  Development 
program.  The  TC  ACCIS  effort  will  provide  an  automated  unit 
movements  data  base  at  the  unit  and  shipper  level,  an  auto- 
mated surge  capability  to  the  installation  transportation 
coordinator,  and  an  automated  interface  between  the 
Installation  Transportation  Office  (ITO)  and  the  associated 
TOA. 

2.   TC  PIS 

A  planned  enhancement  to  the  TC  ACCIS  prototype, 
called  the  Transportation  Coordinator  and  Deployment 
Information  System  (TC  DIS)  ,  includes  an  interface  with 
major  commands  in  an  effort  to  give  them  improved  visibility 
over  the  deployment  status  of  units  assigned  to  them  and 
provides  them  a  capability  to  influence  the  situation.  In 
addition,  TC  DIS  provides  an  interface  directly  from  the 
unit,  where  it  is  generally  agreed  the  most  current  informa- 
tion is  of  necessity  available,  to  the  JDS. 

The  TC  DIS  concept  recognizes  multicommand,  multi- 
functional interfaces  during  the  deployment  management 
process.  Service  and  command  systems  which  already  exist 
can  be  complemented  by  automation  through  electronic  inter- 
faces. Existing  systems  are  generally  stand-alone  func- 
tional systems.  Some  use  notional  data  as  their  basis  for 
initial  planning.  Aging  can  occur  because  data  maintainers 
do  not  always  have  ready  access  to  the  systems  for  updating. 
[Ref.  11:  p.  32] 

C.   SERVICE  SYSTEMS 

Service  systems  which  were  created  at  the  MAJCOM  level 
include  DEMSTAT,  COMPASS,  and  COKPES.  Existing  systems  at 
the  TOA   level  which   provide  networks   for  reporting   vital 
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movement  information  from  support  elements  at  installations 
and  POEs  to  the  TOAs  include  SSMS,  SPUR,  ASPUR,  TOLS,  ME1S, 
and  HAIRS.  Many  of  the  systems  which  exist  at  the  MAJCOM 
level  are  also  located  at  the  installation  level.  These 
systems  usually  have  existing  interfaces  within  the  overall 
system  between  levels,  and  could  potentially  be  connected 
under  the  TC  DIS  concept.  Additionally,  there  are  systems 
still  in  development  phases  which  will  provide  enhancements 
to  the  automation  of  the  deployment  community  information 
requirements. 

1.   MAJCOM  Level  Systems 

a.   DEMSTAT/COMPASS 

The  Deployment,  Employment,  Mobilization  Status 
System  (DEMSTAT)  was  developed  to  provide  Forces  Command 
(FORSCOM)  with  a  system  which  wculd  place  in  execution  those 
plans  developed  in  planning  systems  such  as  JDPS.  It  is 
activated  during  crisis  situations,  and  combines  several 
automated  planning  systems  utilizing  ADP  resources  of 
WWMCCS.  This  system  is  used  tc  identify  units  for  specific 
operations  and  to  manage  those  forces  during  the  execution 
of  the  operation.  When  activated,  the  DEMSTAT  database  is 
the  "sole  source  for  execution  of  all  mobilization/ 
deployment/employment  operations  and  the  operation's  associ- 
ated requirements. "  [fief.  2:  p.  34]  The  database  is  updated 
by  automated  reports  from  FORSCCM  itself,  from  JDA,  and  from 
reporting  commands/installations.   [Ref.  2:  p.  35] 

The  DEMSTAT  system  is  the  execution  system  which 
is  used  in  conjunction  with  the  planning  system  COMPASS. 
The  primary  objective  of  COMPASS  is  to  provide  an  automated 
system  with  unit  movement  information  used  in  mobilization 
and  deployment  planning.  Information  in  COMPASS  is  used  to 
create   the   AUEL    which    provides    the   unit    movement 
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requirements  information  to  MTMC.  These  two  systems  have  no 
real  automated  interface,  although  the  information  in 
COMPASS  is  used  in  DEMSTAT.  There  is  presently  an  interface 
between  DEMSTAT  and  JDS,  where  information  is  transferred 
through  an  existing  automated  interchange  via  AUTODIN, 
although  the  WIN  is  not  used.  DEMSTAT  uses  fewer  fields 
than  JDS,  and  so  when  the  transfers  occur,  the  fields  appro- 
priate to  DEMSTAT  are  stripped  from  the  information  trans- 
ferred by  JDS.  This  interface  is  representative  of  the 
command  to  command  interface  as  discussed  in  Chapter  II. 

b.   COMPES 

The  Contingency  Operation/Mobility  Planning  and 
Execution  System  (COMPES)  ,  an  Air  Force  standard  system,  is 
comprised  of  three  modules:  an  Operation  Plan  Module,  a 
logistics  Module,  and  a  Manpower/Personnel  Module.  This 
system  is  implemented  at  both  the  MAJCOM  and  base  levels 
throughout  the  Air  Force.  Its  functions  include  logistics 
planning  applications  and  monitoring  the  status  of  deployed 
units.  The  Logistics  Module  in  particular  was  designed  to 
satisfy  the  needs  of  both  base-level  and  MAJCOM  logistics 
planners  responsible  for  deployment  planning.  COMPES' 
primary  benefit  is  to  provide  "...a  standard  Air  Force 
deployment  planning  system  which  will  minimize  training 
requirements,  and  provide  a  standard  reference  system  for 
interccmmand  deployment  planning."  [Ref.  2:  p.  23]  There 
are  existing  interfaces  between  COMPES  at  the  MAJCOM  level 
and  the  base  level.  There  are  also  interfaces  between 
COMPES  and  JOPS  and  UNITREP.  Those  interfaces  currently 
involve  data  transfer  via  AUTODIN  using  tape  to  tape  dump. 
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2.      Installation  /TO  A    Level    Systems 

a.  SEMS 

The  Marine  Corps'  Standard  Embarkation 
Management  System  (SEMS)  provides  deployment  planning  docu- 
mentation and  execution  planning  assistance  for  amphibious 
operations  worldwide.  The  information  in  SEMS  includes  unit 
personnel,  supply,  and  equipment  information  at  the  squadron 
and  battalion  level.  Standalone  deployable  minicomputers 
are  used,  with  diskettes  which  can  be  processed  on  the  Fleet 
Marine  Force  (ADPE-FMF)  IBM  4  110  computer.  There  are  no 
current  interfaces  with  other  deployment  systems.  However, 
the  SZMS  is  precisely  the  type  cf  system  which  would  benefit 
from  an  EDI  interchange  as  postulated  in  the  TC  DIS  concept. 
[Ref.  2:  p.  74] 

b.  SPUR/ASPDE 

The  System  for  Predetermining  Unit  Requirements 
(SPUR)  is  "an  initial  step  towards  documentation  simplifica- 
tion aimed  specifically  at  unit  deployments  to  overseas 
locations  under  emergency  conditions."  [Ref.  2:  p.  77]. 
SPUR  obtains  much  of  its  data  from  the  AUEL  generated  by 
COMPASS.  The  information  is  stored  either  in  magnetic  tape 
files  or  disk  packs.   Objectives  of  SPUR  include: 

Eliminate  ITO  of  detailed  Routing  Requests  at  deployment 

Eliminate  unit  submission  of  Advanced  Transportation 
Control  Movement  Document  (ATCMDs)  at  deployment  time 

Reduce  the  MILSTAMP  document  work  load  at  embarkation 
terminals  by  preplacement  of  ATCMDs  in  the  TERMS  data 
base. 

Provide  area  commands  with  an  automated  data  base  of 
unit  leading  information  collected  in  advance.  fRef.  2: 
P-  77] 
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There  are  no  current  interfaces  with  other 
systems.  However,  SPUR  is  the  foundation  for  an  automated 
system  which  is  scheduled  to  become  operational  in  May  1985. 
This  system  (Automated  Systems  for  Processing  Unit 
Requirements  -  ASPUR)  will  ccitinue  to  provide  the  capa- 
bility to  receive  and  process  requirements  from  the  AUEL. 
One  of  its  proposed  primary  functions  is  to  receive, 
process,  and  store  movement  requirements  from  TC  ACCIS  as 
well  as  other  sources  such  as  METS,  TOLS,  and  JDS.  These 
data  transfers  will  be  accomplished  by  using  a  high  speed 
central   processor.      [Ref.    2:    pp.    11-12] 

c.       MAIRS 

The  Military  Air  Integrated  Reporting  System 
(MAIRS)  provides  automated  support  for  the  Military  Airlift 
Command  (MAC).  It  provides  information  such  as  aircraft 
movement  and  delays,  passenger  and  cargo  requirement 
summaries,  and  movenent  data  to  MAC,  MAC  Numbered  Air 
Forces,  and  the  JCS.  There  is  currently  an  interface  with 
AIMS,  another  Air  Porce  automated  system.  There  are  no 
interfaces  with  other  TOA  or  deployment  related  systems, 
although  the  potential  exists  for  interface  with  the  JDS.  A 
test  MAIRS- JDS  interface  has  been  proposed,  which  will 
forward  airlift  arrival/departure  information  to  JDS.  This 
interface  will  utilize  AUTODIN.   £Ref.  2:  pp.  53-54] 

D.   SUMMARY 

Systems  which  represent  significant  advancement  in  the 
automated  interface  arena  are  the  TC  ACCIS  and  the  TC  DIS. 
The  TC  DIS  is  an  enhancement  to  the  TC  ACCIS,  and  will 
provide  a  direct  interface  between  the  unit  and  JDS.  There 
are  a  variety  of  automated  systems  throughout  the  joint 
deployment   community,    with   a    wide   range   of   existing 
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interface  capabilities.  The  potential  exists  within  most  of 
these  systems  for  increased  interfaces,  as  indicated  in 
Figure  2.3.  The  EDI  method  of  interfacing  is  ideal  for  many 
of  these  applications.  Since  each  of  the  systems  described 
above  was  designed  and  developed  by  individuals  for  the 
separate  services,  some  of  the  data  descriptions  and  formats 
may  differ  according  to  the  given  service  requirements.  The 
EDI  concept  is  designed  precisely  to  address  these  types  of 
issues;  therefore,  this  interchange  concept  would  be  appro- 
priate for  interfacing  systems  throughout  the  community. 
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VI.    IMPLEMENTATION    COHSIDEEATIONS^RECOMHEND ATIONS 

A.        INTRODUCTION 

In  order  to  effectively  implement  any  interface  system, 
the  coordination  and  cooperation  of  all  involved  services  or 
agencies  is  essential.  For  the  purpose  of  this  discussion 
those  involved  agencies,  termed  the  Joint  Deployment 
Community    (JDC) ,    are    collectively   referred    to   as 


Those  headquarters,  command,  and  agencies  involved  in 
the  training,  preparation,  movement,  reception,  employ- 
ment, support.,  and  sustainment  of  military  forces 
assigned  or  committed  to  a  theater  of  operations  or 
objective  area.  The  JDC  usually  consists  of  the  OJCS, 
Services,  certain  service  major  commands  {including  the 
Service  wholesale  logistic  commands)  ,  unified  and  speci- 
fied commands  (and  their  service  component  commands) , 
DLA,  the  TOAs,  JDA,  joint  task  forces  (as  applicable), 
and  other  defense  agencies  (e.g.,  DIA)  as  may  be  appro- 
priate to  a   given    scenario.       [Kef.    5:    p.    x] 


It  is  immediately  apparent  that  when  such  a  large  group  of 
diverse  organizations  must  agree  on  any  concept  of  opera- 
tions, problems  are  bound  to  arise.  Therein  lies  a  major 
obstacle  to  the  acceptance  cf  this  proposed  interface 
system. 

B.       JOINT    DEPLOYMENT    COMMUNITY    EEACTIONS 

There  is  almost  unanimous  agreement  throughout  the  JDC 
that  the  need  exists  for  an  automated  interface  between  the 
units,  the  TOAs,  and  JDA.  Additionally,  virtually  all  agree 
that  state  of  the  art  technolcgy  is  readily  available  to 
accomplish  the  necessary  hardware  and  software  connectivity. 
However,  there  is  widespread  disagreement  among  the  various 
participants  regarding  the  required  level  of  interface,  the 
necessary  detail  of  data  exchange,  and  which  particular 
technical   solution    to  implement. 
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Analysis  of  the  JDC  responses  to  the  proposed  TC  ACCIS 
and  TC  DIS  reveals  a  wide  disparity  of  opinions  about  the 
feasibility  of  both  TC  ACCIS  and  the  expanded  capabilities 
of  TC  DIS-  Although  many  representatives  throughout  the 
community  favor  the  overall  concept  of  TC  ACCIS,  there  are 
just  as  many  who  disagree  with  large  portions  of  the  plan. 
Even  among  its  supporters,  there  are  overriding  concerns 
about  the  ability  of  the  community  as  a  whole  to  make  the 
system  work.  Some  cf  the  more  frequently  raised  objections 
are  described  below. 

1  •   110/ JDS  Interface  Necessi ty 

A  primary  concern  is  whether  or  not  there  is  truly  a 
need  for  direct  interface  between  the  automated  unit  data 
base  and  the  JDS.  Such  an  interface  is  proposed  in  the  TC 
DIS  ROC  as  a  one-way  link  with  the  JDS  having  access  to  unit 
data  but  the  unit  having  no  need  for  access  to  the  JDS  data 
base.  This  is  obviously  for  security  purposes,  to  protect 
the  classified  data  maintained  within  JDS.  There  are  a 
number  of  objections  to  this  interface: 

•  One  of  the  basic  premises  in  the  TC  DIS  ROC  is  that  the 
transfer  of  unclassified  unit  information  from  the 
installation  data  base  wculd  be  in  an  unclassified 
mode.  The  assumption  that  all  unit  data  is  unclassi- 
fied is  not  necessarily  valid.  Certain  information 
about  individual  units  when  combined  within  a  partic- 
ular installation's  data  base  becomes  more  sensitive. 

•  In  a  crisis  situation,  the  supported  CINCs  ofctain 
necessary  information  about  the  current  deployment 
status  of  required  forces  and  material  through  the  JDS. 
Much  of  this  information  is  already  available  to  JDS  in 
other  existing  systems.  The  remainder  of  the  required 
information  could  be  obtained  by  JDS  from  the  TOA. 
This  is  especially  true  if  the  proposed 
installation/TOA  interface  can  be  developed. 
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•  There  is  significant  disagreement  concerning  the  level 
of  detailed  data  actually  required  within  the  JDS.  The 
services  tend  to  believe  that  allowing  the  JDS  a  direct 
interface  with  the  units  would  increase  a  perceived 
tendency  on  the  part  of  JDA  to  micro-manage  every 
aspect  of  deployment. 

•  There  is  a  major  'turf  tattle*  ensuing  between  the 
services  and  the  JDA.  The  services  feel  that  the  JDA 
has  more  than  overstepped  its  bounds  by  even  indicating 
that  subordinate  organizations  should  report  directly 
to  them  without  following  through  normal  command  chan- 
nels. None  of  the  services  are  willing  to  give  up 
control  of  their  own  forces  to  this  extent. 

2  •   Sy_s  te  m  Compatibility 

Concern  has  also  been  expressed  that  any  new  system 
development  must  be  made  compatible  with  existing  service 
unique  systems.  There  is  a  feeling  among  the  community  that 
some  aspects  of  TC  ACCIS  are  not  adeguately  considering  this 
compatibility.  Additionally,  the  Joint  Reporting  Structure 
(JRS)  requirements  must  be  carefully  considered  to  enhance 
unit  reporting  and  to  modernize  the  JRS.  A  primary  thought 
here  is  that  TC  ACCIS  implementation  should  be  carefully 
monitored  to  ensure  that  nc  additional  reporting  is 
required. 

3.   Communications  Capacity 

Any  new  interfaces,  regardless  of  the  level,  would 
be  heavily  dependent  on  the  &WMCCS  Intercomputer  Network 
(FIN)  for  the  communications  transfer  of  the  actual  data. 
The  WIN  is  already  severely  taxed  to  satisfy  current 
operational  requirements.  Some  of  the  members  of  the  commu- 
nity feel  that  added  interface  requirements  might  over 
encumber  existing  WWMCCS  facilities. 
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4 .   Securi ty. 

As  already  alluded  to,  there  is  the  significant 
problem  of  data  classification  and  the  security  of  classi- 
fied information.  It  is  inevitable  that  even  unclassified 
data  at  unit  level  will  ultimately  be  classified  at  some 
higher  level  as  it  is  incorporated  into  the  JDS.  The  JDS 
data  base  is  TOP  SECRET.  There  are  many  questions  regarding 
the  ability  to  adequately  protect  potentially  classified 
data  in  an  interface  between  remotely  located  computer 
systems. 

5  .   Modernization  Efforts 

Finally,  all  participants  in  the  JDC  have  expressed 
interest  in  the  evolution  of  both  the  JOPES  and  the  WIS.  It 
is  imperative  that  these  proposed  interfaces  be  developed  in 
conjunction  with  the  flWMCCS  standard  JOPES  and  WIS  efforts. 

C.   EDI  IBPIEMENTATICS  LIMITATIONS  AND  DISADVANTAGES 

Some  of  the  above  issues  suggest  limitations  or  disad- 
vantages to  implementation  of  the  EDI  concept.  Some  of 
these  are  actually  'political'  problems  as  opposed  to  tech- 
nical problems,  and  as  such  are  beyond  the  scope  of  this 
thesis. 

Security  issues  are  a  combination  of  political  and  tech- 
nical problems.  The  EDI  interface  software,  consisting  of 
the  data  elements,  segments  and  sets  and  the  associated 
tables,  do  not  inherently  possess  security  restrictions.  It 
is  assumed  that  the  security  issues  will  be  handled  by  the 
command's  existing  computer  hardware  and  software. 
Determination  of  a.ccess  reguirenents/allowances  must  be  made 
prior  to  concept  implementation;  the  potential  exists  for 
concept  limitations  tased  on  security  requirements. 
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The  disadvantages  associated  with  implementation  of  an 
interface  utilizing  the  EDI  concept  are  primarily  initial 
disadvantages.  The  most  significant  effort  required  would 
be  the  programming  needed.  Each  command  utilizing  the 
concept  will  need  a  program  which  provides  the  interface 
between  their  current  system  and  the  EDI  software.  While 
this  effort  is  substantial,  it  is  for  the  most  part  a  one- 
time operation.  Once  the  program  is  running,  modifications 
to  incorporate  command  changes  are  minor. 

Associated  with  this  interface  software  is  also  the 
computer  time  and  space  required  for  its  operation.  While 
this  differs  from  system  to  system  and  is  thus  hard  to  quan- 
tify in  a  general  sense,  it  dees  reduce  computer  capacity 
available  for  intra-command  operations. 

Another  'cost1  incurred  when  implementing  the  EDI 
concept  is  the  community  wide  requirement  to  identify  data 
sets,  segments,  and  elements  necessary  for  the  interface. 
The  majority  of  these  items  are  in  existence,  as  those 
developed  by  TDCC  are  designed  to  be  applicable  to  a  variety 
of  industries.  In  some  cases,  additional  codes  may  be 
required  to  enable  the  use  of  existing  data  elements.  There 
would  probably  be  more  new  sets  and  segments  required  for 
application  to  the  joint  deployment  community.  It  will 
require  high  level  support  of  the  EDI  concept  to  ensure 
timely  agreement  among  the  users  on  the  exact  makeup  of  the 
new  sets  and  segments.  In  order  to  assist  in  both  the 
creation  of  these  items  and  the  software  design  described 
above,  TDCC  offers  two-day  sessions  intended  to  provide 
selected  individuals  the  necessary  training  and  information. 

Although  this  training  is  available,  the  assistance  of  a 
civilian  company  in  the  software  design  will  likely  be 
required.  There  are  several  companies,  primarily  in  the 
Washington  D.C.  area,  which  can  provide  this  service.  Their 
names  may   be  obtained   from  the  TDCC.     The  cost   for  such 
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assistance  would  be  completely  dependent   upon  the  extent  of 
assistance  required. 

One  potential  political  obstacle  to  the  implementation 
of  the  EDI  concept  is  the  community-wide  acceptance  of  this 
concept  as  the  appropriate  alternative.  The  high  level 
support  and  commitment  required  does  not  presently  exist. 
However,  the  need  for  improvement  in  the  community  today  has 
become  more  apparent,  and  support  for  community-wide  inter- 
face is  growing,  as  evidenced  by  the  money  and  effort 
invested  in  the  TC  ACCIS  and  TC  DIS  programs. 

D.   BENEFITS  OF  EDI 

We  fully  accept  that  all  of  these  concerns  are  valid  and 
we  realize  that  many  of  the  issues  must  be  resolved  before 
any  effort  is  made  toward  implementing  the  system  interfaces 
proposed  by  TC  ACCIS  and  by  this  thesis.  Some  of  the  ques- 
tions raised  are  more  within  the  political  realm  and  must  be 
solved  by  careful  coordination  with  the  agencies  or  organi- 
zations involved.  Those  types  of  issues  are  not  being 
addressed  here. 

However,  many  of  the  supposed  'problems'  would  net  be 
problems  at  all  if  the  EDI  standard  interface  system,  as 
demonstrated  in  this  thesis,  was  adopted  as  the  technical 
solution  to  the  actual  data  exchange  portion  of  the  TC  ACCIS 
and  TC  DIS. 

One  of  the  major  issues  is  the  current  requirement  that 
existing  service  unique  systems  would  have  to  be  converted 
to  be  compatible  with  the  JDS  data  element  structure  in 
order  to  effectively  accomplish  any  interface.  Using  the 
proposed  EDI  system,  there  would  be  no  need  for  the 
interface  data  bases  to  be  maintained  in  identical  format. 
All  existing  and  potential  systems  could  be  designed 
according   to   individual  service   requirements.     The   EDI 
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interface  programs  automatically  perform  the  conversions 
necessary  to  allow  each  system  to  interface  with  the  stan- 
dard data  elements.  This  provides  automatic  interfacing 
between  each  system  and  JDS.  An  added  benefit  of  the  EDI 
conversion  technique  is  that  any  system  can  also  interface 
with  any  other  system  using  the  same  conversion  program. 
Thus  it  is  easily  possible  for  the  three  TOAs  to  have  inter- 
faces with  each  other  as  well  as  the  proposed  interface 
between  the  TOAs  and  JDS. 

There  would  be  seme  effort  required  initially  to  develop 
standard  data  sets  for  transfers  unique  to  military  require- 
ments. However,  the  advantages  of  using  EDI  far  outweigh 
the  time  and  manpower  required  to  establish  these  standard 
data  sets.  First,  once  the  standard  data  sets  are  deter- 
mined, new  systems  can  be  added  and  easily  interfaced  with 
the  addition  of  only  one  new  conversion  program. 

Second,  the  process  of  converting  data  files  into  the 
standard  data  sets  automatically  eliminates  all  but  the 
essential  information  which  must  be  transmitted.  This  would 
significantly  reduce  the  amount  of  extraneous  data  being 
sent  over  already  overloaded  communications  systems.  In 
fact,  use  of  the  standard  data  sets  should  minimize  use  of 
the  WIN,  thus  allowing  it  to  be  available  for  more  interac- 
tive applications. 

Finally,  and  most  notably,  the  adoption  of  the  EDI 
interface  by  the  JDC  would  improve  the  overall  effectiveness 
of  the  joint  deployment  process.  Providing  an  automated 
interface  enabling  direct  connection  between  all  the  partic- 
ipating agencies  would  ensure  that  the  individual  data  bases 
at  each  agency  are  as  much  as  possible  in  agreement  with 
other  agencies  involved.  Thus  when  an  actual  deployment 
must  take  place,  all  concerned  parties  will  have  ready 
access  to  current  data  which  they  require  to  accomplish 
their  given  mission. 
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E.   SUMMARY 

The  necessity  for  continuous  interaction  between  members 
of  the  joint  deployment  community  is  obvious.  Current 
systems  and  interfaces  are  not  providing  the  efficient  and 
accurate  data  transfers  required.  Standardization  is  the 
solution  most  commonly  proposed  to  alleviate  the  current 
situation.  This  proposal,  however,  has  drawbacks  which  have 
been  previously  discussed. 

The  EDI  concept  -  a  table-driven  electronic  interface 
utilizing  data  elements,  segments,  and  sets  -  is  a  proposed 
interface  which  would  provide  the  necessary  data  transfer 
capabilities  throughout  the  community.  While  there  are  many 
concerns  about  implementing  this  system,  most  of  them  are  in 
the  political  realm,  and  are  beyond  the  scope  of  this 
thesis.  The  technical  feasibility  of  the  EDI  concept  has 
been  proven  in  use  in  several  industries  over  the  past  few 
years.  The  application  of  this  system  to  the  military  has 
been  deiaonstrated  in  this  thesis.  Implementation  within  the 
joint  deployment  community  wculd  alleviate  many  of  the 
current  inadequacies  and  provide  an  advanced,  efficient 
means  of  data  transfer  which  would  contribute  to  the  profes- 
sional performance  of  the  joint  deployment  community. 
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DATA  ELEMENT  EICTIONARY 

This  appendix  is  a  partial  EDI  Data  Element  Dictionary. 
The  elements  included  here  are  used  in  the  transaction  set 
shown  in  Appendix  B.  These  elements  correspond  to  the  data 
fields    in  a  user   site's   data   base. 


19  CITY  NAME 

(Spec:   Type 
Free-form  text 

Reference  Desi< 


=  AN 

Min 

=  2: 

Max  = 

19) 

for  ci 

ty  name 

nator  ( 

s)  : 

D40  1 

D701 

D906 

E401 

E701 

F401 

F701 

F906 

G401 

H502 

L715 

N401 

NAM0  5 

h  1 2  0  3 

RT205 

RIN04 

S402 

S903 

T209 

1210 

T604 

T607 

2T03 

U401 

U901 

V905 

W304 

W404 

Y106 

22  COMMODITY  CODE 

(Spec:   Type  =  AN   Min  =  1;  Max  =  10) 
Alpha/numeric  code  used  tc  describe  a  commodity  or 
[roup  of  commodities  for  rating  and  billing  purposes, 
.lso  see:   COMMODITY  CODE  QUALIFIER  (23) 


II 


Reference    Designator (s) :       AC05      E607  GA07  L503 

PR03       PR04  1R03  1R04 

1R05       1R06  1R07  TD104 

TF301    TF302  9T02  W203 
K0111    W0411 


23    COMMODITY    CODE    QUAIIFIER 

(Spec:       Type    =   A      Min    =    1;    Max   =    1) 
Qualifier    for    the    commodity    coding    system    used    to 
define   the  item  lading    description    (See   Appendix    A- 
A6    thru    A13,    A33) 

CODE  DEFINITION 

A  SCHEDULE    A-    tariff   schedules    of    the 

United    States    annotated 
B  U.S.    foreign    trade   SCHEDULE    B,    statistical 

classification   of    domestic   and    foreign 

commodities    exported   form    the    United    States 
C  Canadian    freight    classification 

E  coordinated    motor   freight   classification 

G  Canadian   wheat    board,     grain    code   for 

terminal  elevator   accounting 
H  Brussels  nomenclature    harmonized   system 


(harmonized    BTN) 
LS^' 


I  MILSTAMF 
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L      last  contained  contents  STCC 

M      mutually  defined 

N      national  motor  freight  classification  (NMFC) 

S      standard  international  trade  classification 

(SITC) 
T      standard  transportation  commodity  code  (S1CC) 
U      uniform  freight  classification  (UFC) 
Also  see:   COMMODITY  CODE  (22) 

Reference  Designator (s) :   GA01   L504   1R02   TD103 

ST03   H0110  H0410 


26  COUNTRY  CODE 

(Spec:   Type_=  A   Min  =  2;  Max  =  2) 
Two  character  ISC  standard  country  code 
(See  Appendix  A-A5) 

Reference  Designator (s)  :   1404  D704  D904  E404 

ER001  F404  F704  FS04 

N404  NAM09  R405  R6  10 

S405  S905  U404  US04 


V907   X107k 


65  HEIGHT 

(Spec:   Type  =  D2   Min  =  1:  Max  =  6) 
Vertical  dimension  of  an  otject  measured  when  the 
object  is  in  the  upright  position. 
Also  see:   LENGTH  (32f 

MEASUREMENT  UNI  1  QUALIFIER  (90) 

WIDTH  (189) 

UNIT  OF  MEASUREMENT  CODE  (355) 

Reference  Designator (s)  :   G3907  L403   P0415 


66  IDENTIFICATION  CODE  QUALIFIER 

(Spec:   Type  =AN   Min  =  1;  Max  =  2) 
Type  of  identification  code: 

CODE  DEFINITION 

1  DUNS 

2  SCAC 

3  FMC 

4  IATA 

5  SI  RET 

6  Mutually  defined 

7  DOCK 

8  Vendor    UFC  code 

9  DUNS    with   4    digit    suffix     (UCS    uses 

only    CCDE    9f 
A  Automotive   Industry   Action   Group(AIAG) 

Reference    Designator (s)  :       51101  A1203  A1205  C105 

C202  C401  D102  D503 

1.102  F102  F503  F010J 

10806  F0911  N103  Q407 

S103  S809  U102  U502 


67    IDENTIFICATION    CODE 

(Spec:      Type    =AN      Min   =    2;    Max   =17) 
DUNS,    SCAC,    FMC,    3IRET,    IATA,     UPC,     DUNS    with 
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suffix,    mutually   defined    or   DOCK  code     (See 
Appendix    A-A2,     A16,    A17,     A 18) 

Note:      UCS    uses    only    DUNS    with    suffix. 
Also    see:        IDENTIFICATION    CODE    QUALIFIER     (66) 

Reference    Designator (s) :       A1102  A1204    A1206  C106 

C203  C402       D103  D504 

1103  F103       F504  F0109 

F0602  F0603    F0807  F0912 

K104  0408       S104  S810 

0103  U503 


81     WEIGHT 

(Spec:      Type    =N      Min    =    1 ;    Max    =    8) 
Numeric   Value    of  Weight 
Also    see:       WEIGHT   QUALIFIER    (187) 

WEIGHT    UNIT     QUALIFIER     (188) 
UNIT    OF    MEASUREHENT    CODE     (355) 

Reference   Designator (s)  :       CTT03    F0401  F0404  G505 

G0503    G2004  G3103  G3901 

G7603    GD105  ISS03  L004 

1301       L803  M803  M1105 

N703       Q207  Q402  TD107 

TD305    W0206  W0209  W0302 

¥1210    W1213  W2004  W2106 

W2109    W2507  W2510  W2802 
W7602 


82  LENGTH 

(Spec:   Type  =D2   Min  =  1;  Max  =6) 
Largest  Horizontal  Dimensicn  of  an  Object 
measured  when  the  object  is  in  the  upright 
position. 
Also  see:   HEIGHT  (65) 

MEASUREMENT  UNII  QUALIFIER  (90) 

WIDTH     (189) 

UNIT    OF    MEASUREMENT    CODE     (355) 

Reference    Designator (s)  :       G3909    L401      P0413 

93    NAME 

(Spec:      Type    =AN      Min    =    1;    Max   =    35) 
Free-form    organization    name  or    official  title 
as   it   should    appear   for    mailing    address 

Reference    Designator (s) :       G303      36102    N102      N201 

K202       NAM02    S808       SCH05 
2T01       F6102 
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APPEND 21    B 
TEANSACTIGN    SET    #365 

This    appendix    contains    the    transaction    set,       shown    as   it 
would    be      in    the    EDI      Data    Set    documentation.  This    trans- 

action   set   is      required    for    the   data      transmission    described 
in    Chapter    IV. 


365  UNIT  MOVEMENT  DATA 


ABSTRACT:     This  transaction  set  is  used  by  the  sender  to  transmit 
unit  movement  data  to  other  joint  deployment  community  members. 


Require-    flax     Loop    loop 
nent       Use       IE     Inier 


ST     TRANSACTION  SET  HEADER 

PURPOSE:  To  indicate  the  start  of  a  transaction  set  and  to 
assign  a  control  number 


1 STD1   143  ' 

' STD2  329 

1 ST 

' Transaction ' 
1  Set  ID   1 

1  Transaction 
tSet  Control 

N 

j   A01     | 

1   Number 

L 

|  n  AN  03/03  | 

|  M  AN   04/09 

17  Characters  maximum  lenqth 


M   1   0   0 

"A01"  is  a  special  process  used 
in  the  EDI  interface  software  to 
process  the  set  ID.  version,  & 
functional  ID. 


BGF       BEGINNING  SEGMENT  FOR  FILE  TRANSFER  INFORMATION 
PURPOSE:      To  transmit  identifying  numbers,    dates,    and  other 
basic  data  relating  to  the  transaction  set. 


BGF 


BGF01    128 

Reference 
No.  Qual 

(1      AN      02/02 


BGF02    127 

Reference 
Number 

M     an     01/22 


31   Characters  maximum  lenqth 


N 
L 


M       1       0       0 
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365  UNIT  MOVEMENT  DATA 


Reouire-  flax  Loop  Loop 
nent   Use   ID   Index 


N1  NAME 

PURPOSE:  To  identify  a  party  by  type  of  organization,  name  and  code 


1         '      >N101      98    '      'N1D2         931      ' 

1  N1  j  *  .Organization  *  |       Name       j  *  j 
1        |      j    Identifier    i     |                      ■     i 

I           |       |  H     AN       01/22]        |  C      AN       01/35)       | 

1      !N103         551      lN104         571         ' 

1  *  |     ID  Code     j  -  |     ID  Code     ,   N   | 

Qualifier                PQ304          , 
1      1      p03n4      II                      II 

|   C       AN       01/02)        |   C       AN       02/17) 

M 


0  0 


The  type  of  organization  to  which 
the  nane  is  applied  is  specified 
Dy  a  two  character  code.  The 
definition  for  data  elenent  98 
contains  the  code  list. 

Uhen  N103-N1D4  are  not  used. 
N102  (nane)  is  required. 


63  Characters  maximum  length 


N2  ADDITIONAL  NAME  INFORMATION 
PURPOSE:     To  specify  additional  names,  or  those  longer  than  35 
characters  in  lengtn 


0      2      0     0 

This  is  a  required  segment  if 
additional  information  is 
required  to  completely  specify 
the  nane. 


'N201         93 ' 

!N2Q2        93!      ' 

I  N2 

Name 
|                      | 

I                      I      I 
Name        N 

i           ili 

|  H     AN       01/35) 

|  0      AN       01/35)        | 

75  Characters  maximum  length 


NOTE:    N1  and  N2  are  required  for  the  sending  organization 
and  for  the  receiving  organization. 


72 


365  UNIT  MOVEMENT  DATA 


Reouire-  flax  Loop  Loop 
nent   Use   ID   Index 


Dl  UNIT  IDENTIFICATION 

PURPOSE:  To  specify  unit  identification  code  (UIC) 
and  additional  unit  information 


1         '      '  D101      111  '      '  Dl  02      146 '      '  Dl  03         931      ' 

1  D1  1  "  |        UIC        j  -  |       TyPe       |  *  |      Name      (  -  | 

UMD 

|            |        |  H        AN      06/06)        |  H        AN      01/01)        )  0          AN    01/35)        | 

'0104         191      '0105      1561      ' D106        261      ' 

1        City        II                       II                       II 

State       ,  M  ,     Country       N 
Name       II                                   «             1  i    1 

Cede          L 
1    (Station)    II                      II                      II 

|  0         AN    02/19)       )  C        A       02/02)       |  C        A       02/02)        | 

M  1   0   D 


Uhen  0104  not 
used.  D105-D106 
not  used 


65  characters  maximum  length 


D2  EQUIPMENT  DETAILS 

PURPOSE:  To  provide  equipment  information 


1        '      ' D201       122 

'         '      '        Line 
I    D2    "  I        Item 
I        |      |     Number 

|           |       |  11    AN      06/06 

!D2Q2     324 

Load 
'     Number 

i   0     AN       01/01 

1 D2D3      532 

Line 
1        Index 
1     Number 

)  n    N        02/02 

-  | 

1  D204       24 

Model 

Number 

|  0     AN       01/12 

1 D2D5       64 

Water 
1  Commodity 

1      Code 

|  0     AN       05/05 

'D206      216 

I 

*  I        Type 

Packinq 
I 

|  0     A        02/02 

« 

C  1000  0   0 


Note.  Mandatory  when 
coae  in  segment  N101 
is  JD  (= Joint 

Deploynent  Agency), 
optional  otheruise 
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365  UNIT  MOVEMENT  DATA 


Require-  Max  Loop  loop 
npnt   Use   ID  Index 


D2D7         91 
Mode 


N 
L 


n   a   01/01 


29  characters  maximum  length 


D3  EQUIPMENT  MEASUREMENT 


PURPOSE:      To  describe  physical  dimensions 

1         '      '  D301       372 '      'D302         821      l  D3G3       1891      ' 

'  n?               Item        '                                                     ' 
1        I"  I  Description  |"  1      Len9tn      |"|      Wldth      |"| 

|           |        |  H     AN      01/02   |        |    C     N      01/06    j       |  C     D2      01/06   |        | 

!D304         651      'D305         901      '  D306        811      ' 

1                                             1           '                                             '1                                             If 

'                    '     Measurement     '                    '     ' 
1       Height       1  "  1         Unit         1  "  1      We|ght      1  -  1 
1                      1      1    Qualifier    i      i                      i      i 

|  C     D2      01/06   |        |    C     A       01/01     j        |    H     N      01/08    |       | 

1 D3Q7       1881      'D308       183 '      ' D309       184'      ' 
I      Weight      II                      II     Volume     I  ^  I 

I        Unit        I  "  I     Volume     I  *  I        Unit        I  [_  I 

I    Qualifier    II                       II    Qualifier    I      I 
I  n   a     01/01   |      |  n    n     01/08   |      j  h   a     01/01    |      | 

C    1000  0     0 


Note:     This  data 
segment  required  if 
cooe  in  segnent  N101 
is  JD;  optional 
otherwise 


58  characters  maximum  length 
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365  UNIT  MOVEMENT  DATA 


Require-  flax  Loop  Loop 
nert   Use   10   Index 


D4  CARGO  INFORMATION 
PURPOSE:      To  provide  cargo  information 


1  D4D1       413  ! 

1 D4D2     414   '      ' 

D4 

M         Cargo         ♦ 
'    Category    ' 
I        Code       I 

,         Heavy         ™ 
'         Lift         '  L  ' 
I        Code        I      I 

|  H          AN    03/03 1 

|   M        AN      01/01  |        | 

C       1      0      0 

Note:     This  data  segment  is  required 
if  code  in  segment  N101  is  JD 
(=Joint  Deployment  Agency); 
optional  for  others 


04  characters  maximum  length 


K4  COMMENTS 

PURPOSE:   To  transmit  information  in  a  free-form 

format,  if  necessary,  for  comment  or  special  instruction 


1   0   0 


84  characters  maximum  length 


SE  TRANSACTION  SET  TRAILER 

PURPOSE:  To  indicate  the  end  of  the  transaction  set  and  provide 

the  count  of  the  transmitted  segments  (including  the 

beginning  and  ending  (SE)  segment) 

C   1   0   0 

The  control  nunher  is  the  same  as  that 
used  in  the  corresponding  header. 

Note-  "A16"  and  "A17"  are 
process  identifiers  in  tne  EDI  edit 
taoles  which  are  used  to  construct  or 
check  the  aata  elements  in  the  "SE" 
segment. 


'SEQl         961 

1 SED2      329  •      ' 

1  SE  |  * 

'  Number  of  ' 
1      mcl  seg     1 
1        A16        j 

Trans  set      N 
'  Control  no.  '  ■    ' 
1        A17         I      I 

i  H     AN       01/06    1 

|  n     AN       04/09    |        | 

04  characters  maximum  length 
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APPENDIX  C 
AUTOMATED  UNIT  EQUIPMENT  LISTINGS  (AUELS) 

This  appendix  contains  Automated  Unit  Equipment 
Listings.  The  data  in  these  listings  was  used  in  the  demon- 
stration of  the  EDI  concept,  as  described  in  Chapter  IV.  It 
should  he  noted  that,  although  these  two  listings  contain 
data  from  different  units  (Ft.  Keade  and  Ft.  Ord) ,  the  data 
from  hoth  was  transmitted  in  one  transaction  set  as  shown  in 
Figure    4.3. 
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